Re: [syzbot] [hardening?] [mm?] BUG: bad usercopy in vfs_readlink

From: Mateusz Guzik
Date: Tue Feb 04 2025 - 06:40:13 EST

Next message: Greg KH: "Re: [PATCH 6.6 0/6] md/md-bitmap: move bitmap_{start, end}write to md upper layer"
Previous message: Mika Westerberg: "Re: [PATCH v4] thunderbolt: Disable Gen 4 Recovery on Asymmetric Transitions"
In reply to: syzbot: "[syzbot] [hardening?] [mm?] BUG: bad usercopy in vfs_readlink"
Next in thread: Kees Cook: "Re: [syzbot] [hardening?] [mm?] BUG: bad usercopy in vfs_readlink"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Tue, Feb 4, 2025 at 10:46 AM syzbot
<syzbot+48a99e426f29859818c0@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 69b8923f5003 Merge tag 'for-linus-6.14-ofs4' of git://git...
> git tree: upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=1258aeb0580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=57ab43c279fa614d
> dashboard link: https://syzkaller.appspot.com/bug?extid=48a99e426f29859818c0
> compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15825724580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1658aeb0580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/ea84ac864e92/disk-69b8923f.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/6a465997b4e0/vmlinux-69b8923f.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/d72b67b2bd15/bzImage-69b8923f.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/7c2919610764/mount_0.gz
>
> The issue was bisected to:
>
> commit bae80473f7b0b25772619e7692019b1549d4a82c
> Author: Mateusz Guzik <mjguzik@xxxxxxxxx>
> Date: Wed Nov 20 11:20:35 2024 +0000
>
> ext4: use inode_set_cached_link()
>

This looks like a case of a deliberately corrupted image.

I added back a debug printk I used when writing the patch before. For
correct cases it reports:

[ 19.574861] __ext4_iget: inode ff18d9bec05977c8 [/etc/environment]
i_size 16 strlen 16
[ 19.585987] __ext4_iget: inode ff18d9bed6f25c68
[/etc/alternatives/awk] i_size 21 strlen 21
[ 19.590419] __ext4_iget: inode ff18d9bed6f24108 [/usr/bin/gawk]
i_size 13 strlen 13
[ 19.592199] __ext4_iget: inode ff18d9bed6abeea8
[libassuan.so.0.8.5] i_size 18 strlen 18
[ 19.593804] __ext4_iget: inode ff18d9bed6f29368
[libsigsegv.so.2.0.7] i_size 19 strlen 19

etc.

However, the bogus case is:
[ 52.161476] __ext4_iget: inode ff18d9bed1cc2a38
[/tmp/syz-imagegen43743633/file0/file0] i_size 131109
strlen 37

That is i_size is out of sync with strlen.

Prior to my patch this happened to work because the copying was in
fact issuing strlen to find the size every time.

Given this code in fs/ext4/inode.c:
5008 } else if (ext4_inode_is_fast_symlink(inode)) {
5009 inode->i_op =
&ext4_fast_symlink_inode_operations;
5010 nd_terminate_link(ei->i_data, inode->i_size,
5011 sizeof(ei->i_data) - 1);

To me this looks like a pre-existing bug in ext4 which just happened
to get exposed with:

5012 inode_set_cached_link(inode, (char *)ei->i_data,
5013 inode->i_size);

However, if the strlen thing is indeed the source of truth, the
inode_set_cached_link call can be trivially patched to use it instead
of i_size.

> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1248c3df980000
> final oops: https://syzkaller.appspot.com/x/report.txt?x=1148c3df980000
> console output: https://syzkaller.appspot.com/x/log.txt?x=1648c3df980000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+48a99e426f29859818c0@xxxxxxxxxxxxxxxxxxxxxxxxx
> Fixes: bae80473f7b0 ("ext4: use inode_set_cached_link()")
>
> EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: writeback.
> usercopy: Kernel memory exposure attempt detected from SLUB object 'ext4_inode_cache' (offset 0, size 176)!
> ------------[ cut here ]------------
> kernel BUG at mm/usercopy.c:102!
> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
> CPU: 1 UID: 0 PID: 5826 Comm: syz-executor349 Not tainted 6.13.0-syzkaller-09793-g69b8923f5003 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024
> RIP: 0010:usercopy_abort+0x84/0x90 mm/usercopy.c:102
> Code: 49 89 ce 48 c7 c3 80 5f 18 8c 48 0f 44 de 48 c7 c7 20 5e 18 8c 4c 89 de 48 89 c1 41 52 41 56 53 e8 d1 3a f5 fe 48 83 c4 18 90 <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90
> RSP: 0018:ffffc90003fa7c90 EFLAGS: 00010296
> RAX: 000000000000006b RBX: ffffffff8c185f80 RCX: ba71ae4bd9cf0200
> RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
> RBP: 0000000000000000 R08: ffffffff819f1fbc R09: 1ffff920007f4f2c
> R10: dffffc0000000000 R11: fffff520007f4f2d R12: ffffea0001e70200
> R13: 00000000000000b0 R14: 0000000000000000 R15: 00000000000000b0
> FS: 00005555602a7380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000000000066c7e0 CR3: 0000000078aac000 CR4: 00000000003526f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> <TASK>
> __check_heap_object+0xb1/0x100 mm/slub.c:5818
> check_heap_object mm/usercopy.c:196 [inline]
> __check_object_size+0x1da/0x730 mm/usercopy.c:251
> check_object_size include/linux/thread_info.h:228 [inline]
> check_copy_size include/linux/thread_info.h:264 [inline]
> copy_to_user include/linux/uaccess.h:219 [inline]
> readlink_copy fs/namei.c:5284 [inline]
> vfs_readlink+0x1cf/0x550 fs/namei.c:5307
> do_readlinkat+0x249/0x3a0 fs/stat.c:576
> __do_sys_readlinkat fs/stat.c:593 [inline]
> __se_sys_readlinkat fs/stat.c:590 [inline]
> __x64_sys_readlinkat+0x9a/0xb0 fs/stat.c:590
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7fdaffabc639
> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 61 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffeb88c4948 EFLAGS: 00000246 ORIG_RAX: 000000000000010b
> RAX: ffffffffffffffda RBX: 0030656c69662f2e RCX: 00007fdaffabc639
> RDX: 00000000200002c0 RSI: 0000000020000240 RDI: 00000000ffffff9c
> RBP: 00007fdaffb30610 R08: 0000000000000000 R09: 0000000000000000
> R10: 00000000000000b0 R11: 0000000000000246 R12: 0000000000000001
> R13: 00007ffeb88c4b18 R14: 0000000000000001 R15: 0000000000000001
> </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:usercopy_abort+0x84/0x90 mm/usercopy.c:102
> Code: 49 89 ce 48 c7 c3 80 5f 18 8c 48 0f 44 de 48 c7 c7 20 5e 18 8c 4c 89 de 48 89 c1 41 52 41 56 53 e8 d1 3a f5 fe 48 83 c4 18 90 <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90
> RSP: 0018:ffffc90003fa7c90 EFLAGS: 00010296
> RAX: 000000000000006b RBX: ffffffff8c185f80 RCX: ba71ae4bd9cf0200
> RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
> RBP: 0000000000000000 R08: ffffffff819f1fbc R09: 1ffff920007f4f2c
> R10: dffffc0000000000 R11: fffff520007f4f2d R12: ffffea0001e70200
> R13: 00000000000000b0 R14: 0000000000000000 R15: 00000000000000b0
> FS: 00005555602a7380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000055dd00353bf8 CR3: 0000000078aac000 CR4: 00000000003526f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>
>
> ---
> 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 syzkaller@xxxxxxxxxxxxxxxx.
>
> 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
>
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
>
> If you want syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.
>
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
>
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
>
> If you want to undo deduplication, reply with:
> #syz undup

--
Mateusz Guzik <mjguzik gmail.com>

Next message: Greg KH: "Re: [PATCH 6.6 0/6] md/md-bitmap: move bitmap_{start, end}write to md upper layer"
Previous message: Mika Westerberg: "Re: [PATCH v4] thunderbolt: Disable Gen 4 Recovery on Asymmetric Transitions"
In reply to: syzbot: "[syzbot] [hardening?] [mm?] BUG: bad usercopy in vfs_readlink"
Next in thread: Kees Cook: "Re: [syzbot] [hardening?] [mm?] BUG: bad usercopy in vfs_readlink"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]