Bug 250625 (CVE-2006-6128)

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