linux-kernel - Re: [syzbot] [xfs?] KASAN: slab-out-of-bounds Read in xlog_pack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZI+0yi+V+ziqAQ3Z@dread.disaster.area>
Date:   Mon, 19 Jun 2023 11:52:10 +1000
From:   Dave Chinner <david@...morbit.com>
To:     syzbot <syzbot+b7854dc75e15ffc8c2ae@...kaller.appspotmail.com>
Cc:     djwong@...nel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-xfs@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [xfs?] KASAN: slab-out-of-bounds Read in xlog_pack_data

On Sat, Jun 17, 2023 at 05:23:58P[   65.275181][ T4996] XFS (loop0): Deprecated V4 format (crc=0) will not be supported after September 2030.
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    15adb51c04cc Merge tag 'devicetree-fixes-for-6.4-3' of git..
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=17554263280000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=3731e922b1097b2e
> dashboard link: https://syzkaller.appspot.com/bug?extid=b7854dc75e15ffc8c2ae
> compiler:       Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1323469d280000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12975795280000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/733f46de69b0/disk-15adb51c.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/f9a6a2c566b8/vmlinux-15adb51c.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/55e80680ef0e/bzImage-15adb51c.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/99d5407c555b/mount_0.gz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+b7854dc75e15ffc8c2ae@...kaller.appspotmail.com

 XFS (loop0): Deprecated V4 format (crc=0) will not be supported after September 2030.
 XFS (loop0): Mounting V4 Filesystem acfebfcd-0806-4e27-9777-0ac4ff5ddf54
 XFS (loop0): Log size 756 blocks too small, minimum size is 2220 blocks
 XFS (loop0): Log size out of supported range.
 XFS (loop0): Continuing onwards, but if log hangs are experienced then please report this message in the bug report.
 XFS (loop0): Torn write (CRC failure) detected at log block 0x10. Truncating head block from 0x20.
 XFS (loop0): Ending clean mount
 xfs filesystem being mounted at /root/file0 supports timestamps until 2038-01-19 (0x7fffffff)
 XFS (loop0): Unmounting Filesystem acfebfcd-0806-4e27-9777-0ac4ff5ddf54

<sigh>

Still testing on v4 filesystems.

And with yet another invalid configuration - one that we
explicitly cannot fix for v4 filesystems, yet one that V5
filesystems will immediately reject.

So at this point, the problem "discovered" by syzbot will not
manifest on V5 formats at all.

> xfs filesystem being mounted at /root/file0 supports timestamps until 2038-01-19 (0x7fffffff)
> XFS (loop0): Unmounting Filesystem acfebfcd-0806-4e27-9777-0ac4ff5ddf54
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in xlog_pack_data+0x370/0x540 fs/xfs/xfs_log.c:1822
> Read of size 4 at addr ffff888075c64e00 by task syz-executor205/4996

And, yeah, the issue that is a too-small log on V4 filesystems skips
over other geometry checks (which will still be run on V5) and it's
one of those skipped geometry checks that causes the UAF.

Even if the log was not too small, the specific corruption
that caused the OOB read would have been caught at mount by a V5
filesystem and rejected before anything any attempt to write to the
log occurred.

So here we are again, with syzbot reporting a V4 filesystem issue
that just doesn't happen in the real world, and one that V5
filesystems detect and reject.

And, once again, I'm going to have to modify the code so that V4
filesystems reject stuff that v5 filesystems already reject, even
though no users are actually going to benefit from these changes:

 loop0: detected capacity change from 0 to 65536
 XFS (loop0): log stripe unit 151041 bytes must be a multiple of block size
 XFS (loop0): Metadata corruption detected at xfs_sb_read_verify+0x279/0x2a0, xfs_sb_quiet block 0x0 
 XFS (loop0): Unmount and run xfs_repair
 XFS (loop0): First 128 bytes of corrupted metadata buffer:
 00000000: 58 46 53 42 00 00 08 00 00 00 00 00 00 00 40 00  XFSB..........@.
 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
 00000020: ac fe bf cd 08 06 4e 27 97 77 0a c4 ff 5d df 54  ......N'.w...].T
 00000030: 00 00 00 00 00 00 20 04 00 00 00 00 00 00 00 10  ...... .........
 00000040: 00 00 00 00 00 00 00 11 00 00 00 00 00 00 00 12  ................
 00000050: 00 00 00 02 00 00 20 00 00 00 00 02 00 00 00 00  ...... .........
 00000060: 00 00 02 f4 b4 b4 02 00 04 00 00 02 00 00 00 00  ................
 00000070: 00 00 00 00 00 00 00 00 0b 09 0a 01 0d 00 00 05  ................

Can you please just stop testing V4 filesystems already?

-Dave.
-- 
Dave Chinner
david@...morbit.com