[syzbot] [xfs?] KASAN: null-ptr-deref Write in xfs_filestream_select_ag

20 views
Skip to first unread message

syzbot

unread,
Mar 22, 2023, 4:34:38 AM3/22/23
to dchi...@redhat.com, djw...@kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, syzkall...@googlegroups.com
Hello,

syzbot found the following issue on:

HEAD commit: 17214b70a159 Merge tag 'fsverity-for-linus' of git://git.k..
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=17938109c80000
kernel config: https://syzkaller.appspot.com/x/.config?x=d40f6d44826f6cf7
dashboard link: https://syzkaller.appspot.com/bug?extid=87466712bb342796810a
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=1492946ac80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12e45ad6c80000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/d166fda7fbbd/disk-17214b70.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/0c16461022b9/vmlinux-17214b70.xz
kernel image: https://storage.googleapis.com/syzbot-assets/53e9e40da8bb/bzImage-17214b70.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/52081e4a3707/mount_0.gz

The issue was bisected to:

commit 3e43877a9dac13771ac722462c87bea0bdc50759
Author: Dave Chinner <dchi...@redhat.com>
Date: Sun Feb 12 22:14:55 2023 +0000

xfs: remove xfs_filestream_select_ag() longest extent check

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13cee69ac80000
final oops: https://syzkaller.appspot.com/x/report.txt?x=102ee69ac80000
console output: https://syzkaller.appspot.com/x/log.txt?x=17cee69ac80000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+874667...@syzkaller.appspotmail.com
Fixes: 3e43877a9dac ("xfs: remove xfs_filestream_select_ag() longest extent check")

XFS (loop0): metadata I/O error in "xfs_read_agf+0x2c9/0x600" at daddr 0x1 len 1 error 117
XFS (loop0): page discard on page ffffea0001c573c0, inode 0x2a, pos 0.
==================================================================
BUG: KASAN: null-ptr-deref in instrument_atomic_read_write include/linux/instrumented.h:102 [inline]
BUG: KASAN: null-ptr-deref in atomic_inc include/linux/atomic/atomic-instrumented.h:190 [inline]
BUG: KASAN: null-ptr-deref in xfs_filestream_pick_ag fs/xfs/xfs_filestream.c:156 [inline]
BUG: KASAN: null-ptr-deref in xfs_filestream_create_association fs/xfs/xfs_filestream.c:301 [inline]
BUG: KASAN: null-ptr-deref in xfs_filestream_select_ag+0x14e5/0x1ca0 fs/xfs/xfs_filestream.c:372
Write of size 4 at addr 00000000000001c0 by task kworker/u4:3/47

CPU: 0 PID: 47 Comm: kworker/u4:3 Not tainted 6.3.0-rc3-syzkaller-00012-g17214b70a159 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
Workqueue: writeback wb_workfn (flush-7:0)
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
print_report+0xe6/0x540 mm/kasan/report.c:433
kasan_report+0x176/0x1b0 mm/kasan/report.c:536
kasan_check_range+0x283/0x290 mm/kasan/generic.c:187
instrument_atomic_read_write include/linux/instrumented.h:102 [inline]
atomic_inc include/linux/atomic/atomic-instrumented.h:190 [inline]
xfs_filestream_pick_ag fs/xfs/xfs_filestream.c:156 [inline]
xfs_filestream_create_association fs/xfs/xfs_filestream.c:301 [inline]
xfs_filestream_select_ag+0x14e5/0x1ca0 fs/xfs/xfs_filestream.c:372
xfs_bmap_btalloc_filestreams fs/xfs/libxfs/xfs_bmap.c:3558 [inline]
xfs_bmap_btalloc+0xffa/0x28a0 fs/xfs/libxfs/xfs_bmap.c:3672
xfs_bmapi_allocate+0x647/0xf30
xfs_bmapi_convert_delalloc+0x98f/0x1310 fs/xfs/libxfs/xfs_bmap.c:4554
xfs_convert_blocks fs/xfs/xfs_aops.c:266 [inline]
xfs_map_blocks+0x780/0x1090 fs/xfs/xfs_aops.c:389
iomap_writepage_map fs/iomap/buffered-io.c:1641 [inline]
iomap_do_writepage+0x941/0x2ee0 fs/iomap/buffered-io.c:1803
write_cache_pages+0x89e/0x12c0 mm/page-writeback.c:2473
iomap_writepages+0x68/0x240 fs/iomap/buffered-io.c:1820
xfs_vm_writepages+0x139/0x1a0 fs/xfs/xfs_aops.c:513
do_writepages+0x3a6/0x670 mm/page-writeback.c:2551
__writeback_single_inode+0x155/0xfb0 fs/fs-writeback.c:1600
writeback_sb_inodes+0x8ef/0x11d0 fs/fs-writeback.c:1891
wb_writeback+0x458/0xc70 fs/fs-writeback.c:2065
wb_do_writeback fs/fs-writeback.c:2208 [inline]
wb_workfn+0x400/0xff0 fs/fs-writeback.c:2248
process_one_work+0x8a0/0x10e0 kernel/workqueue.c:2390
worker_thread+0xa63/0x1210 kernel/workqueue.c:2537
kthread+0x270/0x300 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
</TASK>
==================================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

syzbot

unread,
Jan 24, 2024, 3:50:11 AMJan 24
to ax...@kernel.dk, bra...@kernel.org, chanda...@oracle.com, dchi...@redhat.com, djw...@kernel.org, ja...@suse.cz, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, syzkall...@googlegroups.com
syzbot suspects this issue was fixed by commit:

commit 6f861765464f43a71462d52026fbddfc858239a5
Author: Jan Kara <ja...@suse.cz>
Date: Wed Nov 1 17:43:10 2023 +0000

fs: Block writes to mounted block devices

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=119af36be80000
start commit: 17214b70a159 Merge tag 'fsverity-for-linus' of git://git.k..
git tree: upstream
If the result looks correct, please mark the issue as fixed by replying with:

#syz fix: fs: Block writes to mounted block devices

Jan Kara

unread,
Jan 24, 2024, 5:01:24 AMJan 24
to syzbot, ax...@kernel.dk, bra...@kernel.org, chanda...@oracle.com, dchi...@redhat.com, djw...@kernel.org, ja...@suse.cz, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, syzkall...@googlegroups.com
On Wed 24-01-24 00:50:10, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
>
> commit 6f861765464f43a71462d52026fbddfc858239a5
> Author: Jan Kara <ja...@suse.cz>
> Date: Wed Nov 1 17:43:10 2023 +0000
>
> fs: Block writes to mounted block devices
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=119af36be80000
> start commit: 17214b70a159 Merge tag 'fsverity-for-linus' of git://git.k..
> git tree: upstream
> kernel config: https://syzkaller.appspot.com/x/.config?x=d40f6d44826f6cf7
> dashboard link: https://syzkaller.appspot.com/bug?extid=87466712bb342796810a
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1492946ac80000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12e45ad6c80000

So this surprises me a bit because XFS isn't using block device buffer
cache and thus syzbot has no way of corrupting cached metadata even before
these changes. The reproducer tries to mount the loop device again after
mounting the XFS image so I can imagine something bad happens but it isn't
all that clear what. So I'll defer to XFS maintainers whether they want to
mark this bug as fixed or investigate further.

Honza
--
Jan Kara <ja...@suse.com>
SUSE Labs, CR

Dave Chinner

unread,
Jan 24, 2024, 6:08:36 AMJan 24
to Jan Kara, syzbot, ax...@kernel.dk, bra...@kernel.org, chanda...@oracle.com, dchi...@redhat.com, djw...@kernel.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, linu...@vger.kernel.org, syzkall...@googlegroups.com
I've consistently ignored this bug because it is doing stuff with
corrupted V4 XFS filesystems.

The key part of the strace is as follows. /dev/loop0 has been set up
to point to a memfd that maps the reproducer's internal memory. Then
we see:

....
[ 50.859261][ T5070] XFS (loop0): Deprecated V4 format (crc=0) will not be supported after September 2030.
[ 50.869976][ T5070] XFS (loop0): Mounting V4 Filesystem 5e6273b8-2167-42bb-911b-418aa14a1261
[pid 5070] mount("/dev/loop0", "./file0", "xfs", 0, "filestreams,swidth=0x0000000000000000,nodiscard,logbufs=00000000000000000006,attr2,,nouuid") = 0
[pid 5070] openat(AT_FDCWD, "./file0", O_RDONLY|O_DIRECTORY) = 3
[pid 5070] chdir("./file0") = 0
[pid 5070] ioctl(4, LOOP_CLR_FD) = 0
[pid 5070] close(4) = 0
[pid 5070] open("./bus", O_RDWR|O_CREAT|O_TRUNC|O_NONBLOCK|O_SYNC|O_DIRECT|O_LARGEFILE|O_NOATIME, 000) = 4
[pid 5070] mount("/dev/loop0", "./bus", NULL, MS_BIND, NULL) = 0
[pid 5070] open("./bus", O_RDWR|O_NOCTTY|O_SYNC|O_NOATIME|0x3c) = 5
[pid 5070] openat(AT_FDCWD, "memory.current", O_RDWR|O_CREAT|O_NOCTTY|O_TRUNC|O_APPEND|FASYNC|0x18, 000) = 6

And then there's a corruption report and then the KASAN error.

AFAICT, what the reproducer is doing is setting internal memory as
backing device for /dev/loop0, then mounting it, then creating a
file in that XFS filesystem, then doing a bind mount of /dev/loop0
to that file, then opening that file again (which now points to
/dev/loop0) and overwriting it.

As XFS writes back the data to the file, it's actually overwriting
the loop device backing file. i.e. scribbling over the internal
memory of the syzkaller program. The filesystem then goes to read
metadata from the filesystem, and gets back metadata containing:

[ 52.672334][ T4733] 00000000: 66 69 6c 65 73 74 72 65 61 6d 73 2c 73 77 69 64 filestreams,swid
[ 52.681652][ T4733] 00000010: 74 68 3d 30 78 30 30 30 30 30 30 30 30 30 30 30 th=0x00000000000
[ 52.690810][ T4733] 00000020: 30 30 30 30 30 2c 6e 6f 64 69 73 63 61 72 64 2c 00000,nodiscard,
[ 52.700296][ T4733] 00000030: 6c 6f 67 62 75 66 73 3d 30 30 30 30 30 30 30 30 logbufs=00000000
[ 52.709453][ T4733] 00000040: 30 30 30 30 30 30 30 30 30 30 30 36 2c 61 74 74 000000000006,att
[ 52.718572][ T4733] 00000050: 72 32 2c 00 47 ba 76 39 f2 50 ff 99 2f fb b8 b1 r2,.G.v9.P../...
[ 52.728140][ T4733] 00000060: 4c 3a 9b c2 e1 81 d0 9c 24 97 6b 33 7f 55 f4 90 L:......$.k3.U..
[ 52.737174][ T4733] 00000070: 15 4c b3 65 d3 52 86 f0 51 c3 11 75 df a1 cc f1 .L.e.R..Q..u....

The mount options used to mount the filesystem in the first place.

I'd suggest that ithe commit the bisect landed on is blocking the
second open of "./bus" after it was bind mounted to /dev/loop0 and
so the write that corrupts the filesystem image never occurs, and so
the XFS filesystem never trips over that error and hence never
triggers the KASAN warning.

So, yeah, I can see why syzbot might think that commit fixed the
problem. But it didn't - it just broke the reproducer so the
corruption that triggered the problem never manifested...

-Dave.
--
Dave Chinner
da...@fromorbit.com

syzbot

unread,
Apr 2, 2024, 6:17:15 PMApr 2
to syzkall...@googlegroups.com
Auto-closing this bug as obsolete.
No recent activity, existing reproducers are no longer triggering the issue.
Reply all
Reply to author
Forward
0 new messages