Bug 549400 (CVE-2009-4410)

Summary: CVE-2009-4410 kernel: fuse_ioctl_copy_user() dos
Product: [Other] Security Response Reporter: David Shaw <dshaw>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: kmcmartin, pmatouse, security-response-team, tcallawa, vdanen, wmealing
Target Milestone: ---Keywords: Reopened, Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=moderate,public=None,reported=None,source=None,cvss2=4.9/AV:L/AC:L/Au:N/C:N/I:N/A:C,cwe=CWE-628,rhel-5/kernel=notaffected,rhel-6/kernel=notaffected,rhel-7/kernel=notaffected
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-05-18 05:02:31 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 1196850    

Description David Shaw 2009-12-21 10:33:55 EST
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.
Comment 1 David Shaw 2009-12-21 10:35:27 EST
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
Comment 2 Eugene Teo (Security Response) 2009-12-21 10:47:05 EST
Thanks for the report, David. I will look at this as soon as I return from leave on Wednesday. - Eugene
Comment 4 Eugene Teo (Security Response) 2009-12-23 01:29:35 EST
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!
Comment 5 Eugene Teo (Security Response) 2009-12-23 11:26:51 EST
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?
Comment 6 Vincent Danen 2009-12-23 17:17:51 EST
This has been assigned CVE-2009-4410.
Comment 7 Kyle McMartin 2009-12-24 11:10:10 EST
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.
Comment 8 Fedora Update System 2009-12-24 13:35:11 EST
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
Comment 9 Fedora Update System 2009-12-25 03:22:32 EST
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.
Comment 10 David Shaw 2010-06-17 16:10:44 EDT
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.
Comment 11 Eugene Teo (Security Response) 2010-06-17 19:45:54 EDT
Kyle, ping ;)
Comment 12 Kyle McMartin 2010-06-21 06:38:13 EDT
F-11 has been unsupported since the release of F-13, so nothing new can be uploaded. :/
Comment 13 Tomas Hoger 2010-06-21 07:20:36 EDT
It's F-(n+2) GA + 1 month for the official EOL.
Comment 14 Kyle McMartin 2010-06-22 20:38:37 EDT
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
Comment 15 David Shaw 2010-06-22 21:51:24 EDT
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.
Comment 16 Kyle McMartin 2010-06-23 03:27:44 EDT
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@redhat.com> 2.6.30.10-105
- fuse: fix kunmap in fuse_ioctl_copy_user, #549400

Not sure off hand what might be missing.
Comment 17 David Shaw 2010-06-23 11:09:07 EDT
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
Comment 21 Petr Matousek 2015-05-18 05:00:51 EDT
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.
Comment 22 Petr Matousek 2015-05-18 05:02:31 EDT
Cannot reproduce on recent Fedora or any Red Hat product. Closing as NOTABUG.