Created attachment 379640 [details] Program to panic the kernel via fuse Description of problem: There is a problem in the ioctl handler in the fuse kernel code that causes a panic under some circumstances. Version-Release number of selected component (if applicable): fuse-2.8.1-1.fc11.i586 kernel-2.6.30.9-102.fc11.i586 How reproducible: Run the attached program on a fuse filesystem. The kernel should panic. Additional info: This seems to have been fixed upstream already: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0bd87182d3ab18a32a8e9175d3f68754c58e3432 I've checked the 'security' bugzilla bit as it's easy for a regular user to bring the machine down with this.
Here's the output. kernel BUG at mm/highmem.c:260! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/virtual/block/dm-0/range Modules linked in: fuse ipv6 ppdev floppy parport_pc parport i2c_piix4 pcnet32 i2c_core pcspkr mii BusLogic mptspi mptscsih mptbase aic7xxx sym53c8xx scsi_transport_spi [last unloaded: scsi_wait_scan] Pid: 1597, comm: a.out Not tainted (2.6.30.9-96.fc11.i586 #1) VMware Virtual Platform EIP: 0060:[<c0491dbd>] EFLAGS: 00010246 CPU: 0 EIP is at kunmap_high+0x20/0x8f EAX: 00000000 EBX: ff6c0000 ECX: c0a3f100 EDX: 00000a02 ESI: 00000004 EDI: ff6c0004 EBP: f61b5e3c ESP: f61b5e38 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process a.out (pid: 1597, ti=f61b4000 task=f619f1a0 task.ti=f61b4000) Stack: 00000000 f61b5e44 c041fd3e f61b5e74 f80badbb 01000206 ff6c0000 f654a480 f60d8000 00000001 00000004 00000000 f60b25e0 00000000 00000004 f61b5ef8 f80bc7c5 00000004 00000001 00000000 f605b380 f654a480 00000000 f60dbe00 Call Trace: [<c041fd3e>] ? kunmap+0x52/0x54 [<f80badbb>] ? fuse_ioctl_copy_user+0xb8/0xd1 [fuse] [<f80bc7c5>] ? fuse_file_do_ioctl+0x3c1/0x42b [fuse] [<f80bc840>] ? fuse_file_ioctl+0x0/0x14 [fuse] [<f80bc84f>] ? fuse_file_ioctl+0xf/0x14 [fuse] [<c04b5689>] ? vfs_ioctl+0x1d/0x74 [<c04b5b55>] ? do_vfs_ioctl+0x475/0x4af [<c0540e67>] ? selinux_file_ioctl+0x3f/0x42 [<c04b5bd5>] ? sys_ioctl+0x46/0x66 [<c0403535>] ? syscall_call+0x7/0xb Code: c1 e3 0c 81 eb 00 00 00 40 eb e2 55 89 e5 53 0f 1f 44 00 00 89 c3 b8 a0 ba 92 c0 e8 33 a7 29 00 89 d8 e8 2f ff ff ff 85 c0 75 04 <0f> 0b eb fe 8b 15 e0 9a 8c c0 81 ea 00 20 90 00 81 e2 00 00 c0 EIP: [<c0491dbd>] kunmap_high+0x20/0x8f SS:ESP 0068:f61b5e38 ---[ end trace 3ae2055baeb31d7d ]--- Kernel panic - not syncing: Fatal exception Pid: 1597, comm: a.out Tainted: G D 2.6.30.9-96.fc11.i586 #1 Call Trace: [<c072a586>] ? printk+0x14/0x16 [<c072a4d0>] panic+0x3e/0xe0 [<c072d183>] oops_end+0x92/0xa1 [<c0405e14>] die+0x58/0x5e [<c072ca43>] do_trap+0x89/0xa2 [<c040465f>] ? do_invalid_op+0x0/0x85 [<c04046da>] do_invalid_op+0x7b/0x85 [<c0491dbd>] ? kunmap_high+0x20/0x8f [<c0423803>] ? set_next_entity+0xa0/0x10c [<c0402286>] ? __switch_to+0x78/0xfb [<c042428b>] ? pick_next_task_fair+0x87/0x8e [<c072adfe>] ? __schedule+0x761/0x7ab [<c072c7ed>] error_code+0x6d/0x80 [<c040465f>] ? do_invalid_op+0x0/0x85 [<c0491dbd>] ? kunmap_high+0x20/0x8f [<c041fd3e>] kunmap+0x52/0x54 [<f80badbb>] fuse_ioctl_copy_user+0xb8/0xd1 [fuse] [<f80bc7c5>] fuse_file_do_ioctl+0x3c1/0x42b [fuse] [<f80bc840>] ? fuse_file_ioctl+0x0/0x14 [fuse] [<f80bc84f>] fuse_file_ioctl+0xf/0x14 [fuse] [<c04b5689>] vfs_ioctl+0x1d/0x74 [<c04b5b55>] do_vfs_ioctl+0x475/0x4af [<c0540e67>] ? selinux_file_ioctl+0x3f/0x42 [<c04b5bd5>] sys_ioctl+0x46/0x66 [<c0403535>] syscall_call+0x7/0xb
Thanks for the report, David. I will look at this as soon as I return from leave on Wednesday. - Eugene
fuse_ioctl_copy_user() was introduced in 59efec7b (v2.6.29-rc1, 2008-11-26). rhel-5 and below, plus mrg are not affected. 2.6.31/32.y have this fix already. So only distros using 2.6.30.y are affected. I am going to request a CVE name for this, and ping gregkh to get the fix in for 2.6.30.y. Since this fix is public, I will make the bug public but keep the reproducer private. Thanks for the report!
Just got to know from Greg that there won't be anymore 2.6.30.y kernel updates. So, to fix this, we will need to add the patch in our Fedora kernel ourselves. Kyle, are we still supporting 2.6.30.y in F11?
This has been assigned CVE-2009-4410.
Yeah, I'll be updating it and F-12 to 2.6.32 this week while most people are away though so I don't step on any toes. I'll push it to F-11 today though.
kernel-2.6.30.10-105.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/kernel-2.6.30.10-105.fc11
kernel-2.6.30.10-105.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
This problem still exists. I can confirm kernel-2.6.30.10-105.fc11 is okay, but kernel-PAE-2.6.30.10-105.2.23.fc11.i686 still panics with the test program.
Kyle, ping ;)
F-11 has been unsupported since the release of F-13, so nothing new can be uploaded. :/
It's F-(n+2) GA + 1 month for the official EOL.
You are, of course, quite right. This patch does appear to be already applied to the latest F-11 kernel. Can you confirm it's still vulnerable? I'm quite confused, looks like we're missing some upstream commits needed on top of the stable kernel to fix it then. I'm looking at: kernel-2.6.32.10-47.fc11 -Kyle
I was testing with 2.6.30.10-105, which was the latest available via yum so far as I know. Where can I find 2.6.32-10-47 ? In my test, kernel-2.6.30.10-105.fc11 was okay, but the PAE version of the same kernel (kernel-PAE-2.6.30.10-105.2.23.fc11.i686) was not.
Weird, both those kernels contain that commit (2.6.30.10-105 and 2.6.30.10-105.2.23) since * Thu Dec 24 2009 Kyle McMartin <kyle> 2.6.30.10-105 - fuse: fix kunmap in fuse_ioctl_copy_user, #549400 Not sure off hand what might be missing.
Just to sanity check myself, I reproduced this again. kernel-2.6.30.10-105.fc11 fails the ioctl with ENOSYS. kernel-PAE-2.6.30.10-105.2.23.fc11.i686 panics. The only odd detail I can add is that it is somewhat erratic - it sometimes takes 5-10 repetitions of the panic program before the kernel panics. FWIW, here's the crash info: kernel BUG at mm/highmem.c:260! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/virtual/block/dm-1/range Modules linked in: cls_fw sch_sfq sch_htb fuse ipv6 ppdev pcspkr pcnet32 i2c_piix4 floppy parport_pc mii i2c_core parport BusLogic mptspi mptscsih mptbase scsi_transport_spi [last unloaded: scsi_wait_scan] Pid: 1957, comm: panic-fuse Not tainted (2.6.30.10-105.2.23.fc11.i686.PAE #1) VMware Virtual Platform EIP: 0060:[<c0498281>] EFLAGS: 00010246 CPU: 0 EIP is at kunmap_high+0x20/0x8f EAX: 00000000 EBX: ff9ca000 ECX: c0a60f20 EDX: 00000a02 ESI: 00000004 EDI: ff9ca004 EBP: f581de3c ESP: f581de38 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process panic-fuse (pid: 1957, ti=f581c000 task=f6149940 task.ti=f581c000) Stack: 00000000 f581de44 c0425e12 f581de74 f806df3e 01000206 ff9ca000 f619c500 f5808000 00000001 00000004 00000000 f61102f0 00000000 00000004 f581def8 f806f956 00000004 00000001 00000000 f60bb380 f619c500 f5808000 f60a5c00 Call Trace: [<c0425e12>] ? kunmap+0x52/0x54 [<f806df3e>] ? fuse_ioctl_copy_user+0xb5/0xca [fuse] [<f806f956>] ? fuse_file_do_ioctl+0x3ac/0x415 [fuse] [<f806f9d0>] ? fuse_file_ioctl+0x0/0x14 [fuse] [<f806f9df>] ? fuse_file_ioctl+0xf/0x14 [fuse] [<c04bcfdf>] ? vfs_ioctl+0x1d/0x76 [<c04bd4a5>] ? do_vfs_ioctl+0x46d/0x4a7 [<c05488d7>] ? selinux_file_ioctl+0x43/0x46 [<c04bd525>] ? sys_ioctl+0x46/0x66 [<c0408474>] ? sysenter_do_call+0x12/0x28 Code: c1 e3 0c 81 eb 00 00 00 40 eb e2 55 89 e5 53 0f 1f 44 00 00 89 c3 b8 a0 2a 94 c0 e8 17 22 2a 00 89 d8 e8 2f ff ff ff 85 c0 75 04 <0f> 0b eb fe 8b 15 40 b6 8d c0 81 ea 00 20 70 00 81 e2 00 00 e0 EIP: [<c0498281>] kunmap_high+0x20/0x8f SS:ESP 0068:f581de38
Statement: This issue does not affect the Linux kernel packages as shipped with Red Hat Enterprise Linux 5, 6, 7 and Red Hat Enterprise MRG 2.
Cannot reproduce on recent Fedora or any Red Hat product. Closing as NOTABUG.