ext4 info leak in creation times in latest mainline

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

There seems to be a bug in ext4 where the i_crtime of struct ext4_inode_info is not initialised, so (some) creation times contain essentially random values. Here's a report from kmemcheck:

[ 92.402035] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8800168ab208) [ 92.403724] 00000000000000000000000000000000000000000000000018b28a160088ffff [ 92.406378] i i i i i i i i u u u u u u u u i i i i i i i i i i i i i i i i
[   92.408990]                  ^
[ 92.409850] RIP: 0010:[<ffffffff8119d8b6>] [<ffffffff8119d8b6>] ext4_mark_iloc_dirty+0x176/0x670
[   92.411749] RSP: 0018:ffff880016737c18  EFLAGS: 00010206
[ 92.412547] RAX: 000000000000009c RBX: ffff880016737c80 RCX: 0000000000000000 [ 92.413603] RDX: 0000000000000000 RSI: ffff8800168aaf70 RDI: ffff8800168aaf20 [ 92.414664] RBP: ffff880016737c68 R08: 0000080000010000 R09: ffff880017d11680 [ 92.415732] R10: ffff8800168aaf20 R11: 0000000000000000 R12: ffff8800168611a0 [ 92.416789] R13: ffff880017d11600 R14: ffff880016683800 R15: ffff8800168aafd0 [ 92.417859] FS: 00007f3997461700(0000) GS:ffff880017a00000(0000) knlGS:0000000000000000
[   92.419051] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 92.419891] CR2: ffff880017404160 CR3: 0000000016351000 CR4: 00000000000006f0 [ 92.420946] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 92.422120] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
[   92.423371]  [<ffffffff8119dec1>] ext4_mark_inode_dirty+0x71/0x1b0
[   92.424858]  [<ffffffff811a0b64>] ext4_dirty_inode+0x44/0x70
[   92.425853]  [<ffffffff81148169>] __mark_inode_dirty+0x29/0x200
[   92.427432]  [<ffffffff8113ae79>] update_time+0x79/0xc0
[   92.428236]  [<ffffffff8113b09a>] touch_atime+0xfa/0x140
[   92.429105]  [<ffffffff810d6cee>] generic_file_aio_read+0x4ae/0x6b0
[   92.430076]  [<ffffffff81120d55>] do_sync_read+0x55/0x90
[   92.430874]  [<ffffffff81121d46>] vfs_read+0xa6/0x180
[   92.431648]  [<ffffffff81121fbd>] SyS_read+0x4d/0xa0

RIP here corresponds to the line:

    EXT4_EINODE_SET_XTIME(i_crtime, ei, raw_inode);

in ext4_do_update_inode(), in particular the

    (raw_inode)->xtime = cpu_to_le32((einode)->xtime.tv_sec);

line of EXT4_EINODE_SET_XTIME. As an aside, kmemcheck reports a 64-bit read, but that's just because gcc generates a 64-bit load followed by a 32-bit store, so it essentially just discards the upper 32 bits:

ffffffff8119d8b6:       49 8b 87 38 02 00 00    mov    0x238(%r15),%rax
ffffffff8119d8bd:       41 89 85 90 00 00 00    mov    %eax,0x90(%r13)

A few of the weird crtimes I've observed (using debugfs):

crtime: 0x00000101:00000000 -- Thu Jan  1 00:04:17 1970
crtime: 0x00001000:00000000 -- Thu Jan  1 01:08:16 1970
crtime: 0x02020202:00000002 -- Mon Jan 25 21:13:38 1971 (looks like some kind of poison value?)
crtime: 0x03030303:00000003 -- Sun Aug  8 19:50:27 1971
crtime: 0x15406b80:00000000 -- Sun Apr 19 15:49:20 1981 (these look like lower 32 bits of stack addresses/kernel pointers)
crtime: 0x16be86a0:00000000 -- Wed Feb  3 11:50:56 1982
crtime: 0x2f0d5ac1:00000000 -- Fri Jan  6 14:59:13 1995

And enabling SLUB debugging removes any trace of a doubt:

crtime: 0x5a5a5a5a:00000002 -- Sat Jan 13 19:13:30 2018

I don't know if it's relevant, but the filesystem is actually ext3 mounted using ext4. It's 100% reproducible for me, so I can test patches.


Vegard
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux