Re: Intentionally corrupted vfat fs causing BUG

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

 



On Fri, Oct 10, 2014 at 10:57 PM, Sami Liedes <sami.liedes@xxxxxx> wrote:
> Hi!
>
> I ran some fuzz tests on a vfat filesystem on 3.17 and found a
> filesystem that differs from a pristine filesystem by one bit and
> causes a kernel BUG. This seems to be an old bug; I can also replicate
> it on a 3.3.4 kernel I happened to have lying around.
>
> The set of operations I run for filesystems is this:
>
>    mount $TARGET_DEV /mnt -t vfat
>    cd /mnt
>    timeout 30 cp -r doc doc2 >&/dev/null
>    timeout 30 find -xdev >&/dev/null
>    timeout 30 find -xdev -print0 2>/dev/null |xargs -0 touch -- >&/dev/null
>    timeout 30 mkdir tmp >&/dev/null
>    timeout 30 echo whoah >tmp/filu >&/dev/null
>    timeout 30 rm -rf /mnt/* >&/dev/null
>    cd /
>    umount /mnt
>
> The backtrace seems to indicate that the BUG happens at the rm phase.
>
> You can get the pristine filesystem from
>
>    http://www.niksula.hut.fi/~sliedes/vfat/testimg.vfat.bz2
>
> The broken filesystem is at
>
>    http://www.niksula.hut.fi/~sliedes/vfat/testimg.vfat.24.min.bz2
>
> The only difference is this one bit:
>
> --- /dev/fd/63  2014-10-10 23:23:09.424422610 +0300
> +++ /dev/fd/62  2014-10-10 23:23:09.424422610 +0300
> @@ -1977,7 +1977,7 @@
>  0008d230  08 39 08 39 00 00 bc 0d  08 39 13 00 00 00 00 00  |.9.9.....9......|
>  0008d240  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
>  *
> -0008da00  2e 20 20 20 20 20 20 20  20 20 20 10 00 00 bc 0d  |.          .....|
> +0008da00  2e 20 20 20 20 20 20 20  20 20 60 10 00 00 bc 0d  |.         `.....|

The issue here is that this directory entry is faulty.
Usually each entry has a "." entry which points to itself. In your image
the ->name is different. Hence, there is no "." but a directory named
".         `"
which points to itself.
IOW a directory loop.

The vFAT file system misses to check whether there is really a "." and
".." directory.
These directories are the only ones which are allowed to be hard links.
And it misses to detect loops which triggers the BUG_ON() in the VFS core.
For the latter issue I'm not unsure where to fix this.
Al?

>  0008da10  08 39 08 39 00 00 bc 0d  08 39 0b 01 00 00 00 00  |.9.9.....9......|
>  0008da20  2e 2e 20 20 20 20 20 20  20 20 20 10 00 00 bc 0d  |..         .....|
>  0008da30  08 39 08 39 00 00 bc 0d  08 39 13 00 00 00 00 00  |.9.9.....9......|
>
>
> Backtrace on 3.17:
>
> [    1.363073] ------------[ cut here ]------------
> [    1.363437] kernel BUG at fs/namei.c:2430!
> [    1.363749] invalid opcode: 0000 [#1] SMP
> [    1.364088] CPU: 0 PID: 889 Comm: rm Not tainted 3.17.0+ #32
> [    1.364517] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
> [    1.365291] task: ffff880000066360 ti: ffff8800063b0000 task.ti: ffff8800063b0000
> [    1.365813] RIP: 0010:[<ffffffff8116c998>]  [<ffffffff8116c998>] may_delete+0x128/0x140
> [    1.365813] RSP: 0018:ffff8800063b3e38  EFLAGS: 00010293
> [    1.365813] RAX: ffff8800065cf120 RBX: ffff8800065cf240 RCX: ffff8800000663b0
> [    1.365813] RDX: 0000000000000001 RSI: ffff8800065cf240 RDI: ffff880006631858
> [    1.365813] RBP: ffff8800063b3e58 R08: 0000000000000000 R09: 0000000000000001
> [    1.365813] R10: 0000000000000000 R11: 0000000000000044 R12: ffff8800066313b0
> [    1.365813] R13: ffff880006631858 R14: 0000000000000007 R15: 00000000fffffffe
> [    1.365813] FS:  0000000000000000(0000) GS:ffff880007c00000(0063) knlGS:00000000f7609940
> [    1.365813] CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
> [    1.365813] CR2: 00000000ff967000 CR3: 000000000637f000 CR4: 00000000000006b0
> [    1.365813] Stack:
> [    1.365813]  ffff8800065cf240 0000000000000000 ffff880006631858 0000000000000007
> [    1.365813]  ffff8800063b3e80 ffffffff81173699 ffff880006334000 0000000000000000
> [    1.365813]  0000000008faf1e4 ffff8800063b3f68 ffffffff81173905 ffff8800065cf240
> [    1.365813] Call Trace:
> [    1.365813]  [<ffffffff81173699>] vfs_rmdir+0x19/0xf0
> [    1.365813]  [<ffffffff81173905>] do_rmdir+0x195/0x1d0
> [    1.365813]  [<ffffffff810aa11d>] ? trace_hardirqs_on_caller+0x15d/0x200
> [    1.365813]  [<ffffffff8165e9cb>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [    1.365813]  [<ffffffff81173d95>] SyS_unlinkat+0x25/0x40
> [    1.365813]  [<ffffffff8188e888>] sysenter_dispatch+0x7/0x2a
> [    1.365813] Code: 41 5e 5d c3 0f 1f 80 00 00 00 00 b8 ff ff ff ff eb c4 90 0f 0b 66 0f 1f 44 00 00 48 39 5b 40 75 a2 b8 f0 ff ff ff eb ae 0f 1f 00 <0f> 0b 66 0f 1f 44 00 00 b8 fe ff ff ff eb 9c 66 0f 1f 84 00 00
> [    1.365813] RIP  [<ffffffff8116c998>] may_delete+0x128/0x140
> [    1.365813]  RSP <ffff8800063b3e38>
> [    1.378725] ---[ end trace 15817999647273ef ]---
> [    1.379086] Kernel panic - not syncing: Fatal exception
> [    1.379592] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
> [    1.380349] Rebooting in 1 seconds..
>
>         Sami
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux