dumpkeys --funcs-only fails with the following error messages KDGKBSENT: bad address KDGKBSENT failed at index 0 In tracking this down, I discovered that drivers/char/vt_ioctl.c, function do_kdgkb_ioctl, line 358 begins a loop that calls put_user repeatedly. This function returns with a failure on 2.6.32-hardened-r9 and -r10 kernels, but not on 2.6.28-hardened-r9 kernel, or 2.6.34-gentoo-r1 kernel. In addition, simply adding a printk statement to the line immediately preceeding the call to put_user in vt_ioctl.c makes the problem go away. That makes this problem smell potentially like some sort of thread-race condition. do_kdgkb_ioctl did not change between 2.6.28-hardened-r9 and 2.6.32-hardened-r10. However, digging into the code for put_user reveals that arch/x86/include/asm/uaccess.h was heavily modified between 2.6.28-hardened-r9 and 2.6.32-hardened-r9. The 2.6.28-hardened-r9 version of this file appears to be fairly similar to the 2.6.34-gentoo-r1 version, but is significantly different from the 2.6.32 hardened versions. Reproducible: Always Steps to Reproduce: 1. Emerge 2.6.32-hardened-r10 (or -r9) kernel and install 2. Reboot with new kernel 3. Run dumpkeys --funcs-only Actual Results: Observe that keymaps init script fails with errors mentioned above Observe that dumpkeys fails with errors mentioned above Expected Results: System runs without errors. This is happening on a dual quad-core system. The system is a Supermicro X8DA3 motherboard, with 2 Intel 5520 Xeon quad-core cpus and 12 GB of ram.
Created attachment 238197 [details] 2.6.32-hardened-r10 kernel config
Created attachment 238199 [details] system emerge --info
I hit your bug using your config. The bug is config dependent because I have another config where it does not happen. I will try to narrow the gap between our configs before posting that one so we have more info. As you noticed, putting a printk just before the effect lines relieves the problem. However, it is not the calls to put_user() in the loop that are the problem, but the call immediately after: --- vt_ioctl.c.orig 2010-07-11 12:24:13.000000000 +0000 +++ vt_ioctl.c 2010-07-11 12:49:33.000000000 +0000 @@ -360,10 +360,12 @@ ret = -EFAULT; goto reterr; } + printk("GENTOO BUG 327667:before\n"); if (put_user('\0', up)) { ret = -EFAULT; goto reterr; } + //printk("GENTOO BUG 327667:after\n"); kfree(kbs); return ((p && *p) ? -EOVERFLOW : 0); case KDSKBSENT: With this patch dumpkeys --funcs-only works and dmesg reports: [ 467.352361] GENTOO BUG 327667:before [ 467.352364] GENTOO BUG 327667:before [ 467.352367] GENTOO BUG 327667:before [ 467.352370] GENTOO BUG 327667:before [ 467.352373] GENTOO BUG 327667:before many times. If, however, you comment out the before prinkt and uncomment the after printk you get the failure returns and there is no printk message in dmesgs.
I think I found it. Can the reporter please deselect CONFIG_PAX_MEMORY_UDEREF and test again.
Deselecting CONFIG_PAX_MEMORY_UDEREF appears to resolve the problem.
This has been fixed by upstream in sys-kernel/hardened-sources-2.6.32-r11.
