Description of problem: The ReiserFS functionality in Linux kernel 2.6.18, and possibly other versions, allows local users to cause a denial of service via a malformed ReiserFS file system that triggers memory corruption when a sync is performed. http://projects.info-pull.com/mokb/MOKB-25-11-2006.html
BUG: unable to handle kernel paging request at virtual address 00010179 printing eip: c048cee3 *pde = 00000000 Oops: 0002 [#1] SMP last sysfs file: /block/loop7/range Modules linked in: reiserfs jfs loop ipv6 sunrpc ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables video sbs i2c_ec button battery asus_acpi ac parport_pc lp parport snd_ens1371 gameport snd_rawmidi snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq floppy snd_seq_device sg snd_pcm_oss snd_mixer_oss snd_pcm i2c_piix4 pcspkr snd_timer snd soundcore pcnet32 snd_page_alloc i2c_core mii serio_raw ide_cd cdrom dm_snapshot dm_zero dm_mirror dm_mod mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd CPU: 1 EIP: 0060:[<c048cee3>] Not tainted VLI EFLAGS: 00010203 (2.6.18-1.2849.fc6 #1) EIP is at set_sb_syncing+0x14/0x2c eax: 00010101 ebx: 00000000 ecx: c067b720 edx: 00000001 esi: 0804a785 edi: bfb73ec4 ebp: cfbb3000 esp: cfbb3f9c ds: 007b es: 007b ss: 0068 Process sync (pid: 5171, ti=cfbb3000 task=cc6eb5f0 task.ti=cfbb3000) Stack: 00000000 c048d6f0 00000001 c04718c2 0804a785 0804c4d4 c0471913 c0404013 0804c4d4 00000000 00000001 0804a785 bfb73ec4 bfb73e28 00000024 0000007b 0000007b 00000024 00c9a402 00000073 00000246 bfb73de8 0000007b 00000000 Call Trace: [<c048d6f0>] sync_inodes+0xa/0x29 [<c04718c2>] do_sync+0x14/0x5b [<c0471913>] sys_sync+0xa/0xd [<c0404013>] syscall_call+0x7/0xb
I thought this got fixed on later kernels?
Dave: it is very likely, though I haven't seen CVE-2006-6128 referenced in any kernel updates. The issue was originally reported against 2.6.18-1.2849.fc6 -- the subsequent one is 2.6.19-1.2895.fc6 [FEDORA-2007-058]. The only changelog that contains stuff related to reiserfs is 2.6.19 [1], however I can't tell whether any of the changes there fix the problem -- do they? [1] http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.19
I can reproduce it on 2.6.18-1.2798.fc6 / x86 but not on the latest F8 kernel... now, whether this was an intentional fix or we just got lucky I'm not sure. I don't immediately see anything in the 2.6.19 changelog that looks related... -Eric
Appears fixed by 2.6.20-1.2933.fc6, though... *sigh* the tedium...! :)
2.6.19-1.2911.fc6 also seems ok. So something in 2.6.19 did fix it, apparently. At least we're not still vulnerable; I'll narrow down what changed later this evening if I have the time.
Ok, I think this was actually a buggy patch in fedora's 2.6.18 kernels. :( linux-2.6-reiserfs-dentry-ref.patch did: - .kill_sb = kill_block_super, + .kill_sb = reiserfs_kill_sb, and then: +static void reiserfs_kill_sb(struct super_block *s) +{ + if (REISERFS_SB(s)) { + if (REISERFS_SB(s)->xattr_root) { + d_invalidate(REISERFS_SB(s)->xattr_root); + dput(REISERFS_SB(s)->xattr_root); + REISERFS_SB(s)->xattr_root = NULL; + } + if (REISERFS_SB(s)->priv_root) { + d_invalidate(REISERFS_SB(s)->priv_root); + dput(REISERFS_SB(s)->priv_root); + REISERFS_SB(s)->priv_root = NULL; + } + kill_block_super(s); + } +} but that means the VFS superblock never goes through kill_block_super if the reiser-specific SB isn't there. Upstream is: static void reiserfs_kill_sb(struct super_block *s) { if (REISERFS_SB(s)) { #ifdef CONFIG_REISERFS_FS_XATTR if (REISERFS_SB(s)->xattr_root) { d_invalidate(REISERFS_SB(s)->xattr_root); dput(REISERFS_SB(s)->xattr_root); REISERFS_SB(s)->xattr_root = NULL; } #endif if (REISERFS_SB(s)->priv_root) { d_invalidate(REISERFS_SB(s)->priv_root); dput(REISERFS_SB(s)->priv_root); REISERFS_SB(s)->priv_root = NULL; } } kill_block_super(s); } i.e. call kill_block_super in all cases. (see also http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=edc666e2ff9ec2e4e9510f1127c68c22cffc93f6) w/o that kill_block_super the half-set-up superblock is hanging around on a failed mount, waiting to go boom. -Eric