Created attachment 1198213 [details] reproducer Description of problem: I was testing new program using kernel keyring service when I was hit by following bug. After some time I managed to minimize the reproducer into quite simple one (attached as C source code). I filled the security field but so far I'm not sure it's really security bug or not. I took better safe than sorry approach, I'm really not an expert here. Also the reproducer proves that if kernel stack protector is enabled any user with access to the system may kill it running the reproducer (due to stack protector steps in). Version-Release number of selected component (if applicable): kernel-4.7.2-201.fc24 kernel-4.7.2 upstream (with stack protector enabled) all 4.8-rcX kernels (with stack protector enabled) How reproducible: 100% Steps to Reproduce: Run attached reproducer The system hangs if kernel is compiled with stack protector enabled. Actual results: Kernel stack protector 'kills' the system [-- MARK -- Tue Sep 6 11:40:00 2016 .. Tue Sep 6 12:10:00 2016 -- MARK --] [ 2080.261944] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81352ebe [ 2080.261944] [ 2080.263263] CPU: 0 PID: 1692 Comm: reproducer Not tainted 4.7.2-201.fc24.x86_64 #1 [ 2080.264024] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2080.264605] 0000000000000086 00000000fbbd2679 ffff8800a044bc00 ffffffff813d941f [ 2080.265401] ffffffff81a28d58 ffff8800a044bc98 ffff8800a044bc88 ffffffff811b2cb6 [ 2080.266192] ffff880000000010 ffff8800a044bc98 ffff8800a044bc30 00000000fbbd2679 [ 2080.266983] Call Trace: [ 2080.267268] [<ffffffff813d941f>] dump_stack+0x63/0x84 [ 2080.267802] [<ffffffff811b2cb6>] panic+0xde/0x22a [ 2080.268297] [<ffffffff81352ebe>] ? proc_keys_show+0x3ce/0x3d0 [ 2080.268896] [<ffffffff8109f7f9>] __stack_chk_fail+0x19/0x30 [ 2080.269471] [<ffffffff81352ebe>] proc_keys_show+0x3ce/0x3d0 [ 2080.270046] [<ffffffff81350410>] ? key_validate+0x50/0x50 [ 2080.270597] [<ffffffff8134db30>] ? key_default_cmp+0x20/0x20 [ 2080.271184] [<ffffffff8126b31c>] seq_read+0x2cc/0x390 [ 2080.271711] [<ffffffff812b6b12>] proc_reg_read+0x42/0x70 [ 2080.272258] [<ffffffff81244fc7>] __vfs_read+0x37/0x150 [ 2080.272790] [<ffffffff81357020>] ? security_file_permission+0xa0/0xc0 [ 2080.273444] [<ffffffff81246156>] vfs_read+0x96/0x130 [ 2080.273957] [<ffffffff81247635>] SyS_read+0x55/0xc0 [ 2080.274469] [<ffffffff817eb872>] entry_SYSCALL_64_fastpath+0x1a/0xa4 [ 2080.276165] Kernel Offset: disabled [ 2080.276602] ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81352ebe [ 2080.276602] I'm managed to reproduce it on 4.7.2 kernel with Fedora 24 and also on all 4.8-rc kernels with stack protector enabled.
Created attachment 1198288 [details] Fix for buffer overflow in proc_keys_show
Just adding that I tested the attached patch and stack protector seems to be happy now. Couldn't reproduce it on 4.8-rc5 kernel anymore.
Probably the bug is present in older kernels as well, but David should know better than me...
cve-id CVE-2016-7042 was assigned to this flaw internally by the Red Hat. please, use it in the public communications regarding this flaw.
I got this [37840.608719] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffffa02e08ae [37840.608779] CPU: 2 PID: 8625 Comm: cat Not tainted 4.8.5-1-foo #1 [37840.608806] Hardware name: Gigabyte Technology Co., Ltd. Z170X-UD3/Z170X-UD3-CF, BIOS F6 03/01/2016 [37840.608844] 0000000000000086 000000005412530d ffffffffa032e60c ffffa607c24f6000 [37840.608884] ffffa606c210bca8 ffffffffa010919d ffffa60b00000010 ffffa606c210bcb8 [37840.608923] ffffa606c210bc50 000000005412530d ffffa607c24f6008 ffffffffa02e08ae [37840.608962] Call Trace: [37840.608983] [<ffffffffa032e60c>] ? dump_stack+0x46/0x5a [37840.609011] [<ffffffffa010919d>] ? panic+0xd9/0x215 [37840.609037] [<ffffffffa02e08ae>] ? proc_keys_show+0x3ae/0x3b0 [37840.609065] [<ffffffffa00686b0>] ? __stack_chk_fail+0x10/0x20 [37840.609091] [<ffffffffa02e08ae>] ? proc_keys_show+0x3ae/0x3b0 [37840.609136] [<ffffffffa02de300>] ? key_validate+0x50/0x50 [37840.609163] [<ffffffffa02dbcd0>] ? key_default_cmp+0x20/0x20 [37840.609193] [<ffffffffa0181feb>] ? seq_read+0xfb/0x3c0 [37840.609218] [<ffffffffa01b5778>] ? proc_reg_read+0x38/0x60 [37840.609246] [<ffffffffa015e73e>] ? __vfs_read+0x2e/0x130 [37840.609271] [<ffffffffa0134c51>] ? handle_mm_fault+0x3b1/0xdb0 [37840.609300] [<ffffffffa015f43c>] ? vfs_read+0x8c/0x130 [37840.609325] [<ffffffffa016086d>] ? SyS_read+0x4d/0xc0 [37840.609349] [<ffffffffa0002556>] ? do_syscall_64+0x46/0x90 [37840.609376] [<ffffffffa076e2fc>] ? entry_SYSCALL64_slow_path+0x25/0x25 [37840.609436] Kernel Offset: 0x1f000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) today on stock kernel after playing around with keyctl on vanilla 4.8.5 (not rhel/fedora) .. is this not fixed or different bug?
Hi Sverd, the fix got in 4.9-rc3 (commit 03dab869b7b239c4e013). Not sure when it'll be pulled in stables though but it's been sent to stables as well.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs. Fedora 25 has now been rebased to 4.10.9-100.fc24. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.