Bug#872623: kbd: setmetamode fails with StackSmashing detected
Control: tags 872623 + fixed-upstream On Mon, May 28, 2018 at 09:31:53PM +0200, Andreas Henriksson wrote: > Control: forwarded -1 https://github.com/legionus/kbd/pull/16 > Control: tags -1 + upstream [...] Now merged upstream and will be part of the next upstream release (v2.0.5 ?). https://github.com/legionus/kbd/commit/6613abc26a853293c12f4e146a27606f02c8dd03 Regards, Andreas Henriksson
Bug#872623: kbd: setmetamode fails with StackSmashing detected
Control: forwarded -1 https://github.com/legionus/kbd/pull/16 Control: tags -1 + upstream Hello, Sorry for the late followup. On Sat, Aug 19, 2017 at 04:08:50PM -0400, alsau...@pragmasoft.com wrote: [...] > Upon closer examination, it appears that the KDGKBMETA IOCTL that > is called by setmetamode.c, is subsequently calling: >put_user (, (int __user*) arg); > > Unfortunately, the argument (ometa) is only declared as "char" in > setmetamode.c. So, in essence, we are asking the kernel to store > an into a user space location that has only been > allocated as a "char". > > I now believe that the appropriate correction is to change the > "char ometa, nmeta;" declaration in setmetamode.c to > "unsigned int ometa, nmeta;". During my testing, this change > eliminated the StackSmashing detection and subsequent traceback. [...] I agree with your analysis. Would be best to discuss this issue upstream, but since the fix seemed obvious I went ahead and submitted https://github.com/legionus/kbd/pull/16 Thanks for your detailed bug report and analysis. Regards, Andreas Henriksson
Bug#872623: kbd: setmetamode fails with StackSmashing detected
As a follow-up to my initial post ... Obviously, changing the return statement in setmetamode.c is only a "band-aid" that restores operation, but does nothing to correct the underlying problem. Upon closer examination, it appears that the KDGKBMETA IOCTL that is called by setmetamode.c, is subsequently calling: put_user (, (int __user*) arg); Unfortunately, the argument (ometa) is only declared as "char" in setmetamode.c. So, in essence, we are asking the kernel to store an into a user space location that has only been allocated as a "char". I now believe that the appropriate correction is to change the "char ometa, nmeta;" declaration in setmetamode.c to "unsigned int ometa, nmeta;". During my testing, this change eliminated the StackSmashing detection and subsequent traceback. If this problem and analysis is confirmed by other users, I would hope that this fix could be propagated into a subsequent Stretch update so as to restore operation of the setmetamode utility.
Bug#872623: kbd: setmetamode fails with StackSmashing detected
Package: kbd Version: 2.0.3-2+b1 Severity: normal Dear Maintainer, Standard Stretch release. Running "setmetamode esc" (or setmetamode meta) results in a report that StackSmashing was detected and subsequent stack traceback messages. Although by no means an expert, I -believe- that the problem is with the last line of setmetamode.c, which reads "return EXIT_SUCCESS;". In my tests, replacing this with "exit(EXIT_SUCCESS);" eliminated the StackSmashing detection and traceback messages. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kbd depends on: ii libc6 2.24-11+deb9u1 ii lsb-base 9.20161125 Versions of packages kbd recommends: ii console-setup 1.164 kbd suggests no packages. -- no debconf information
