[syzbot] [ext4?] KASAN: out-of-bounds Read in ext4_xattr_set_entry

[syzbot] [ext4?] KASAN: out-of-bounds Read in ext4_xattr_set_entry

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    a940d9a43e62 Merge tag 'soc-arm-6.12' of git://git.kernel...
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16689207980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=1653f803fffa3848
dashboard link: https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1
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=11689207980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=104d469f980000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7bc7510fe41f/non_bootable_disk-a940d9a4.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/371e11b6a9e5/vmlinux-a940d9a4.xz
kernel image: https://storage.googleapis.com/syzbot-assets/920eb0c53785/bzImage-a940d9a4.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/4146c0b2e744/mount_0.gz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com

EXT4-fs (loop0): 1 truncate cleaned up
EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: writeback.
==================================================================
BUG: KASAN: out-of-bounds in ext4_xattr_set_entry+0x8ce/0x1f60 fs/ext4/xattr.c:1781
Read of size 18446744073709551572 at addr ffff888036426850 by task syz-executor264/5095

CPU: 0 UID: 0 PID: 5095 Comm: syz-executor264 Not tainted 6.11.0-syzkaller-03917-ga940d9a43e62 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:93 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
 __asan_memmove+0x29/0x70 mm/kasan/shadow.c:94
 ext4_xattr_set_entry+0x8ce/0x1f60 fs/ext4/xattr.c:1781
 ext4_xattr_block_set+0xa39/0x3980 fs/ext4/xattr.c:2028
 ext4_xattr_move_to_block fs/ext4/xattr.c:2669 [inline]
 ext4_xattr_make_inode_space fs/ext4/xattr.c:2744 [inline]
 ext4_expand_extra_isize_ea+0x12d7/0x1cf0 fs/ext4/xattr.c:2836
 __ext4_expand_extra_isize+0x2fb/0x3e0 fs/ext4/inode.c:5858
 ext4_try_to_expand_extra_isize fs/ext4/inode.c:5901 [inline]
 __ext4_mark_inode_dirty+0x524/0x880 fs/ext4/inode.c:5979
 __ext4_unlink+0x6c2/0xb50 fs/ext4/namei.c:3289
 ext4_unlink+0x1bf/0x5a0 fs/ext4/namei.c:3318
 vfs_unlink+0x365/0x650 fs/namei.c:4469
 do_unlinkat+0x4ae/0x830 fs/namei.c:4533
 __do_sys_unlink fs/namei.c:4581 [inline]
 __se_sys_unlink fs/namei.c:4579 [inline]
 __x64_sys_unlink+0x47/0x50 fs/namei.c:4579
 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:0x7f2549cabe99
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 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:00007fff914df8a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000057
RAX: ffffffffffffffda RBX: 0031656c69662f2e RCX: 00007f2549cabe99
RDX: 00007f2549cabe99 RSI: 00007f2549cabe99 RDI: 0000000020000180
RBP: 0032656c69662f2e R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff914df8e0
R13: 00007fff914dfb08 R14: 431bde82d7b634db R15: 00007f2549cf503b
 </TASK>

Allocated by task 5095:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
 poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
 __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
 kasan_kmalloc include/linux/kasan.h:211 [inline]
 __do_kmalloc_node mm/slub.c:4159 [inline]
 __kmalloc_node_track_caller_noprof+0x225/0x440 mm/slub.c:4178
 kmemdup_noprof+0x2a/0x60 mm/util.c:133
 ext4_xattr_block_set+0x88b/0x3980 fs/ext4/xattr.c:1976
 ext4_xattr_move_to_block fs/ext4/xattr.c:2669 [inline]
 ext4_xattr_make_inode_space fs/ext4/xattr.c:2744 [inline]
 ext4_expand_extra_isize_ea+0x12d7/0x1cf0 fs/ext4/xattr.c:2836
 __ext4_expand_extra_isize+0x2fb/0x3e0 fs/ext4/inode.c:5858
 ext4_try_to_expand_extra_isize fs/ext4/inode.c:5901 [inline]
 __ext4_mark_inode_dirty+0x524/0x880 fs/ext4/inode.c:5979
 __ext4_unlink+0x6c2/0xb50 fs/ext4/namei.c:3289
 ext4_unlink+0x1bf/0x5a0 fs/ext4/namei.c:3318
 vfs_unlink+0x365/0x650 fs/namei.c:4469
 do_unlinkat+0x4ae/0x830 fs/namei.c:4533
 __do_sys_unlink fs/namei.c:4581 [inline]
 __se_sys_unlink fs/namei.c:4579 [inline]
 __x64_sys_unlink+0x47/0x50 fs/namei.c:4579
 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

The buggy address belongs to the object at ffff888036426800
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 80 bytes inside of
 1024-byte region [ffff888036426800, ffff888036426c00)

The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x36424
head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x4fff00000000040(head|node=1|zone=1|lastcpupid=0x7ff)
page_type: 0xfdffffff(slab)
raw: 04fff00000000040 ffff88801ac41dc0 dead000000000100 dead000000000122
raw: 0000000000000000 0000000080080008 00000001fdffffff 0000000000000000
head: 04fff00000000040 ffff88801ac41dc0 dead000000000100 dead000000000122
head: 0000000000000000 0000000080080008 00000001fdffffff 0000000000000000
head: 04fff00000000002 ffffea0000d90901 ffffffffffffffff 0000000000000000
head: 0000000000000004 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 2, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5049, tgid 5049 (dhcpcd), ts 74832155643, free_ts 73695396465
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1500
 prep_new_page mm/page_alloc.c:1508 [inline]
 get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3446
 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4702
 __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]
 alloc_pages_node_noprof include/linux/gfp.h:296 [inline]
 alloc_slab_page+0x5f/0x120 mm/slub.c:2319
 allocate_slab+0x5a/0x2f0 mm/slub.c:2482
 new_slab mm/slub.c:2535 [inline]
 ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3721
 __slab_alloc+0x58/0xa0 mm/slub.c:3811
 __slab_alloc_node mm/slub.c:3864 [inline]
 slab_alloc_node mm/slub.c:4026 [inline]
 __do_kmalloc_node mm/slub.c:4158 [inline]
 __kmalloc_noprof+0x25a/0x400 mm/slub.c:4171
 kmalloc_noprof include/linux/slab.h:694 [inline]
 load_elf_phdrs+0x162/0x260 fs/binfmt_elf.c:526
 load_elf_binary+0x920/0x2680 fs/binfmt_elf.c:955
 search_binary_handler fs/exec.c:1820 [inline]
 exec_binprm fs/exec.c:1862 [inline]
 bprm_execve+0xaf8/0x1770 fs/exec.c:1913
 do_execveat_common+0x55f/0x6f0 fs/exec.c:2020
 do_execve fs/exec.c:2094 [inline]
 __do_sys_execve fs/exec.c:2170 [inline]
 __se_sys_execve fs/exec.c:2165 [inline]
 __x64_sys_execve+0x92/0xb0 fs/exec.c:2165
 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
page last free pid 5032 tgid 5032 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 free_pages_prepare mm/page_alloc.c:1101 [inline]
 free_unref_page+0xd22/0xea0 mm/page_alloc.c:2619
 __slab_free+0x31b/0x3d0 mm/slub.c:4385
 qlink_free mm/kasan/quarantine.c:163 [inline]
 qlist_free_all+0x9e/0x140 mm/kasan/quarantine.c:179
 kasan_quarantine_reduce+0x14f/0x170 mm/kasan/quarantine.c:286
 __kasan_slab_alloc+0x23/0x80 mm/kasan/common.c:322
 kasan_slab_alloc include/linux/kasan.h:201 [inline]
 slab_post_alloc_hook mm/slub.c:3989 [inline]
 slab_alloc_node mm/slub.c:4038 [inline]
 __do_kmalloc_node mm/slub.c:4158 [inline]
 __kmalloc_noprof+0x1a6/0x400 mm/slub.c:4171
 kmalloc_noprof include/linux/slab.h:694 [inline]
 tomoyo_realpath_from_path+0xcf/0x5e0 security/tomoyo/realpath.c:251
 tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
 tomoyo_path_perm+0x2b7/0x740 security/tomoyo/file.c:822
 security_inode_getattr+0x130/0x330 security/security.c:2371
 vfs_getattr+0x45/0x430 fs/stat.c:204
 vfs_fstat fs/stat.c:229 [inline]
 vfs_fstatat+0xe4/0x190 fs/stat.c:338
 __do_sys_newfstatat fs/stat.c:505 [inline]
 __se_sys_newfstatat fs/stat.c:499 [inline]
 __x64_sys_newfstatat+0x11d/0x1a0 fs/stat.c:499
 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

Memory state around the buggy address:
 ffff888036426700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff888036426780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888036426800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                                                 ^
 ffff888036426880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff888036426900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================


---
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@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

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

Re: [syzbot] [ext4?] KASAN: out-of-bounds Read in ext4_xattr_set_entry

[Qianqiang Liu]

On Sat, Sep 21, 2024 at 05:16:22PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    a940d9a43e62 Merge tag 'soc-arm-6.12' of git://git.kernel...
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16689207980000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=1653f803fffa3848
> dashboard link: https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1
> 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=11689207980000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=104d469f980000
> 
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7bc7510fe41f/non_bootable_disk-a940d9a4.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/371e11b6a9e5/vmlinux-a940d9a4.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/920eb0c53785/bzImage-a940d9a4.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/4146c0b2e744/mount_0.gz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com
> 
> EXT4-fs (loop0): 1 truncate cleaned up
> EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: writeback.
> ==================================================================
> BUG: KASAN: out-of-bounds in ext4_xattr_set_entry+0x8ce/0x1f60 fs/ext4/xattr.c:1781
> Read of size 18446744073709551572 at addr ffff888036426850 by task syz-executor264/5095
> 
> CPU: 0 UID: 0 PID: 5095 Comm: syz-executor264 Not tainted 6.11.0-syzkaller-03917-ga940d9a43e62 #0
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
> Call Trace:
>  <TASK>
>  __dump_stack lib/dump_stack.c:93 [inline]
>  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
>  print_address_description mm/kasan/report.c:377 [inline]
>  print_report+0x169/0x550 mm/kasan/report.c:488
>  kasan_report+0x143/0x180 mm/kasan/report.c:601
>  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
>  __asan_memmove+0x29/0x70 mm/kasan/shadow.c:94
>  ext4_xattr_set_entry+0x8ce/0x1f60 fs/ext4/xattr.c:1781
>  ext4_xattr_block_set+0xa39/0x3980 fs/ext4/xattr.c:2028
>  ext4_xattr_move_to_block fs/ext4/xattr.c:2669 [inline]
>  ext4_xattr_make_inode_space fs/ext4/xattr.c:2744 [inline]
>  ext4_expand_extra_isize_ea+0x12d7/0x1cf0 fs/ext4/xattr.c:2836
>  __ext4_expand_extra_isize+0x2fb/0x3e0 fs/ext4/inode.c:5858
>  ext4_try_to_expand_extra_isize fs/ext4/inode.c:5901 [inline]
>  __ext4_mark_inode_dirty+0x524/0x880 fs/ext4/inode.c:5979
>  __ext4_unlink+0x6c2/0xb50 fs/ext4/namei.c:3289
>  ext4_unlink+0x1bf/0x5a0 fs/ext4/namei.c:3318
>  vfs_unlink+0x365/0x650 fs/namei.c:4469
>  do_unlinkat+0x4ae/0x830 fs/namei.c:4533
>  __do_sys_unlink fs/namei.c:4581 [inline]
>  __se_sys_unlink fs/namei.c:4579 [inline]
>  __x64_sys_unlink+0x47/0x50 fs/namei.c:4579
>  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:0x7f2549cabe99
> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 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:00007fff914df8a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000057
> RAX: ffffffffffffffda RBX: 0031656c69662f2e RCX: 00007f2549cabe99
> RDX: 00007f2549cabe99 RSI: 00007f2549cabe99 RDI: 0000000020000180
> RBP: 0032656c69662f2e R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff914df8e0
> R13: 00007fff914dfb08 R14: 431bde82d7b634db R15: 00007f2549cf503b
>  </TASK>
> 
> Allocated by task 5095:
>  kasan_save_stack mm/kasan/common.c:47 [inline]
>  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
>  poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
>  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
>  kasan_kmalloc include/linux/kasan.h:211 [inline]
>  __do_kmalloc_node mm/slub.c:4159 [inline]
>  __kmalloc_node_track_caller_noprof+0x225/0x440 mm/slub.c:4178
>  kmemdup_noprof+0x2a/0x60 mm/util.c:133
>  ext4_xattr_block_set+0x88b/0x3980 fs/ext4/xattr.c:1976
>  ext4_xattr_move_to_block fs/ext4/xattr.c:2669 [inline]
>  ext4_xattr_make_inode_space fs/ext4/xattr.c:2744 [inline]
>  ext4_expand_extra_isize_ea+0x12d7/0x1cf0 fs/ext4/xattr.c:2836
>  __ext4_expand_extra_isize+0x2fb/0x3e0 fs/ext4/inode.c:5858
>  ext4_try_to_expand_extra_isize fs/ext4/inode.c:5901 [inline]
>  __ext4_mark_inode_dirty+0x524/0x880 fs/ext4/inode.c:5979
>  __ext4_unlink+0x6c2/0xb50 fs/ext4/namei.c:3289
>  ext4_unlink+0x1bf/0x5a0 fs/ext4/namei.c:3318
>  vfs_unlink+0x365/0x650 fs/namei.c:4469
>  do_unlinkat+0x4ae/0x830 fs/namei.c:4533
>  __do_sys_unlink fs/namei.c:4581 [inline]
>  __se_sys_unlink fs/namei.c:4579 [inline]
>  __x64_sys_unlink+0x47/0x50 fs/namei.c:4579
>  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
> 
> The buggy address belongs to the object at ffff888036426800
>  which belongs to the cache kmalloc-1k of size 1024
> The buggy address is located 80 bytes inside of
>  1024-byte region [ffff888036426800, ffff888036426c00)
> 
> The buggy address belongs to the physical page:
> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x36424
> head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> flags: 0x4fff00000000040(head|node=1|zone=1|lastcpupid=0x7ff)
> page_type: 0xfdffffff(slab)
> raw: 04fff00000000040 ffff88801ac41dc0 dead000000000100 dead000000000122
> raw: 0000000000000000 0000000080080008 00000001fdffffff 0000000000000000
> head: 04fff00000000040 ffff88801ac41dc0 dead000000000100 dead000000000122
> head: 0000000000000000 0000000080080008 00000001fdffffff 0000000000000000
> head: 04fff00000000002 ffffea0000d90901 ffffffffffffffff 0000000000000000
> head: 0000000000000004 0000000000000000 00000000ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
> page_owner tracks the page as allocated
> page last allocated via order 2, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5049, tgid 5049 (dhcpcd), ts 74832155643, free_ts 73695396465
>  set_page_owner include/linux/page_owner.h:32 [inline]
>  post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1500
>  prep_new_page mm/page_alloc.c:1508 [inline]
>  get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3446
>  __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4702
>  __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]
>  alloc_pages_node_noprof include/linux/gfp.h:296 [inline]
>  alloc_slab_page+0x5f/0x120 mm/slub.c:2319
>  allocate_slab+0x5a/0x2f0 mm/slub.c:2482
>  new_slab mm/slub.c:2535 [inline]
>  ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3721
>  __slab_alloc+0x58/0xa0 mm/slub.c:3811
>  __slab_alloc_node mm/slub.c:3864 [inline]
>  slab_alloc_node mm/slub.c:4026 [inline]
>  __do_kmalloc_node mm/slub.c:4158 [inline]
>  __kmalloc_noprof+0x25a/0x400 mm/slub.c:4171
>  kmalloc_noprof include/linux/slab.h:694 [inline]
>  load_elf_phdrs+0x162/0x260 fs/binfmt_elf.c:526
>  load_elf_binary+0x920/0x2680 fs/binfmt_elf.c:955
>  search_binary_handler fs/exec.c:1820 [inline]
>  exec_binprm fs/exec.c:1862 [inline]
>  bprm_execve+0xaf8/0x1770 fs/exec.c:1913
>  do_execveat_common+0x55f/0x6f0 fs/exec.c:2020
>  do_execve fs/exec.c:2094 [inline]
>  __do_sys_execve fs/exec.c:2170 [inline]
>  __se_sys_execve fs/exec.c:2165 [inline]
>  __x64_sys_execve+0x92/0xb0 fs/exec.c:2165
>  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
> page last free pid 5032 tgid 5032 stack trace:
>  reset_page_owner include/linux/page_owner.h:25 [inline]
>  free_pages_prepare mm/page_alloc.c:1101 [inline]
>  free_unref_page+0xd22/0xea0 mm/page_alloc.c:2619
>  __slab_free+0x31b/0x3d0 mm/slub.c:4385
>  qlink_free mm/kasan/quarantine.c:163 [inline]
>  qlist_free_all+0x9e/0x140 mm/kasan/quarantine.c:179
>  kasan_quarantine_reduce+0x14f/0x170 mm/kasan/quarantine.c:286
>  __kasan_slab_alloc+0x23/0x80 mm/kasan/common.c:322
>  kasan_slab_alloc include/linux/kasan.h:201 [inline]
>  slab_post_alloc_hook mm/slub.c:3989 [inline]
>  slab_alloc_node mm/slub.c:4038 [inline]
>  __do_kmalloc_node mm/slub.c:4158 [inline]
>  __kmalloc_noprof+0x1a6/0x400 mm/slub.c:4171
>  kmalloc_noprof include/linux/slab.h:694 [inline]
>  tomoyo_realpath_from_path+0xcf/0x5e0 security/tomoyo/realpath.c:251
>  tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
>  tomoyo_path_perm+0x2b7/0x740 security/tomoyo/file.c:822
>  security_inode_getattr+0x130/0x330 security/security.c:2371
>  vfs_getattr+0x45/0x430 fs/stat.c:204
>  vfs_fstat fs/stat.c:229 [inline]
>  vfs_fstatat+0xe4/0x190 fs/stat.c:338
>  __do_sys_newfstatat fs/stat.c:505 [inline]
>  __se_sys_newfstatat fs/stat.c:499 [inline]
>  __x64_sys_newfstatat+0x11d/0x1a0 fs/stat.c:499
>  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
> 
> Memory state around the buggy address:
>  ffff888036426700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  ffff888036426780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >ffff888036426800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>                                                  ^
>  ffff888036426880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  ffff888036426900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==================================================================
> 
> 
> ---
> 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@googlegroups.com.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> 
> 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
> 

#syz test

diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 46ce2f21fef9..336badb46246 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1776,7 +1776,14 @@ static int ext4_xattr_set_entry(struct ext4_xattr_info *i,
 	} else if (s->not_found) {
 		/* Insert new name. */
 		size_t size = EXT4_XATTR_LEN(name_len);
-		size_t rest = (void *)last - (void *)here + sizeof(__u32);
+		size_t rest;
+
+		if (last < here) {
+			ret = -ENOSPC;
+			goto out;
+		} else {
+			rest = (void *)last - (void *)here + sizeof(__u32);
+		}
 
 		memmove((void *)here + size, here, rest);
 		memset(here, 0, size);
-- 
Best,
Qianqiang Liu

Re: [syzbot] [ext4?] KASAN: out-of-bounds Read in ext4_xattr_set_entry

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com
Tested-by: syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com

Tested on:

commit:         88264981 Merge tag 'sched_ext-for-6.12' of git://git.k..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17c78e07980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=5b5c53071a819d59
dashboard link: https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=16538e07980000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [ext4?] KASAN: out-of-bounds Read in ext4_xattr_set_entry

[Qianqiang Liu]

#syz test

diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index e0e1956dcdd3..649b278d4c1f 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1884,7 +1884,7 @@ ext4_xattr_block_find(struct inode *inode, struct ext4_xattr_info *i,
 		bs->s.here = bs->s.first;
 		error = xattr_find_entry(inode, &bs->s.here, bs->s.end,
 					 i->name_index, i->name, 1);
-		if (error && error != -ENODATA)
+		if (error)
 			return error;
 		bs->s.not_found = error;
 	}

-- 
Best,
Qianqiang Liu

Re: [syzbot] [ext4?] KASAN: out-of-bounds Read in ext4_xattr_set_entry

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com
Tested-by: syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com

Tested on:

commit:         e32cde8d Merge tag 'sched_ext-for-6.12-rc1-fixes-1' of..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13657dd0580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=286b31f2cf1c36b5
dashboard link: https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=122da580580000

Note: testing is done by a robot and is best-effort only.

[PATCH] ext4: xattr: fix wrong search.here in clone_block

[Jinchao Wang]

syzbot reported a KASAN out-of-bounds Read in ext4_xattr_set_entry()[1].

When xattr_find_entry() returns -ENODATA, search.here still points to the
position after the last valid entry. ext4_xattr_block_set() clones the xattr
block because the original block maybe shared and must not be modified in
place.

In the clone_block, search.here is recomputed unconditionally from the old
offset, which may place it past search.first. This results in a negative
reset size and an out-of-bounds memmove() in ext4_xattr_set_entry().

Fix this by initializing search.here correctly when search.not_found is set.

[1] https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1

Fixes: fd48e9acdf2 (ext4: Unindent codeblock in ext4_xattr_block_set)
Cc: stable@vger.kernel.org
Reported-by: syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com
Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
---
 fs/ext4/xattr.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 2e02efbddaac..cc30abeb7f30 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1980,7 +1980,10 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
 			goto cleanup;
 		s->first = ENTRY(header(s->base)+1);
 		header(s->base)->h_refcount = cpu_to_le32(1);
-		s->here = ENTRY(s->base + offset);
+		if (s->not_found)
+			s->here = s->first;
+		else
+			s->here = ENTRY(s->base + offset);
 		s->end = s->base + bs->bh->b_size;
 
 		/*
-- 
2.43.0

Re: [PATCH] ext4: xattr: fix wrong search.here in clone_block

[Jinchao Wang]

On Tue, Dec 16, 2025 at 07:34:55PM +0800, Jinchao Wang wrote:
> syzbot reported a KASAN out-of-bounds Read in ext4_xattr_set_entry()[1].
> 
> When xattr_find_entry() returns -ENODATA, search.here still points to the
> position after the last valid entry. ext4_xattr_block_set() clones the xattr
> block because the original block maybe shared and must not be modified in
> place.
> 
> In the clone_block, search.here is recomputed unconditionally from the old
> offset, which may place it past search.first. This results in a negative
> reset size and an out-of-bounds memmove() in ext4_xattr_set_entry().
> 
> Fix this by initializing search.here correctly when search.not_found is set.
> 
> [1] https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1
> 
> Fixes: fd48e9acdf2 (ext4: Unindent codeblock in ext4_xattr_block_set)
> Cc: stable@vger.kernel.org
> Reported-by: syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com
> Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
> ---
>  fs/ext4/xattr.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
> index 2e02efbddaac..cc30abeb7f30 100644
> --- a/fs/ext4/xattr.c
> +++ b/fs/ext4/xattr.c
> @@ -1980,7 +1980,10 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
>  			goto cleanup;
>  		s->first = ENTRY(header(s->base)+1);
>  		header(s->base)->h_refcount = cpu_to_le32(1);
> -		s->here = ENTRY(s->base + offset);
> +		if (s->not_found)
> +			s->here = s->first;
> +		else
> +			s->here = ENTRY(s->base + offset);
>  		s->end = s->base + bs->bh->b_size;
>  
>  		/*
> -- 
> 2.43.0
> 

#syz test

Re: [syzbot] [ext4?] KASAN: out-of-bounds Read in ext4_xattr_set_entry

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: out-of-bounds Read in ext4_xattr_set_entry

EXT4-fs (loop0): 1 truncate cleaned up
EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: writeback.
==================================================================
BUG: KASAN: out-of-bounds in ext4_xattr_set_entry+0x8e9/0x1e20 fs/ext4/xattr.c:1782
Read of size 18446744073709551572 at addr ffff88800077a050 by task syz.0.17/5873

CPU: 0 UID: 0 PID: 5873 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xca/0x240 mm/kasan/report.c:482
 kasan_report+0x118/0x150 mm/kasan/report.c:595
 check_region_inline mm/kasan/generic.c:-1 [inline]
 kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200
 __asan_memmove+0x29/0x70 mm/kasan/shadow.c:94
 ext4_xattr_set_entry+0x8e9/0x1e20 fs/ext4/xattr.c:1782
 ext4_xattr_block_set+0x872/0x2ac0 fs/ext4/xattr.c:2029
 ext4_xattr_move_to_block fs/ext4/xattr.c:2668 [inline]
 ext4_xattr_make_inode_space fs/ext4/xattr.c:2743 [inline]
 ext4_expand_extra_isize_ea+0x12da/0x1ea0 fs/ext4/xattr.c:2831
 __ext4_expand_extra_isize+0x30d/0x400 fs/ext4/inode.c:6349
 ext4_try_to_expand_extra_isize fs/ext4/inode.c:6392 [inline]
 __ext4_mark_inode_dirty+0x45c/0x6e0 fs/ext4/inode.c:6470
 __ext4_unlink+0x631/0xab0 fs/ext4/namei.c:3282
 ext4_unlink+0x206/0x590 fs/ext4/namei.c:3312
 vfs_unlink+0x380/0x640 fs/namei.c:5369
 do_unlinkat+0x2cf/0x560 fs/namei.c:5439
 __do_sys_unlink fs/namei.c:5474 [inline]
 __se_sys_unlink fs/namei.c:5472 [inline]
 __x64_sys_unlink+0x47/0x50 fs/namei.c:5472
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ff419d8f7c9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ff41abdb038 EFLAGS: 00000246 ORIG_RAX: 0000000000000057
RAX: ffffffffffffffda RBX: 00007ff419fe5fa0 RCX: 00007ff419d8f7c9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000180
RBP: 00007ff419e13f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ff419fe6038 R14: 00007ff419fe5fa0 R15: 00007fff883d93a8
 </TASK>

Allocated by task 5873:
 kasan_save_stack mm/kasan/common.c:56 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:77
 poison_kmalloc_redzone mm/kasan/common.c:397 [inline]
 __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:414
 kasan_kmalloc include/linux/kasan.h:262 [inline]
 __do_kmalloc_node mm/slub.c:5657 [inline]
 __kmalloc_node_track_caller_noprof+0x575/0x820 mm/slub.c:5764
 kmemdup_noprof+0x2b/0x70 mm/util.c:138
 kmemdup_noprof include/linux/fortify-string.h:765 [inline]
 ext4_xattr_block_set+0x781/0x2ac0 fs/ext4/xattr.c:1977
 ext4_xattr_move_to_block fs/ext4/xattr.c:2668 [inline]
 ext4_xattr_make_inode_space fs/ext4/xattr.c:2743 [inline]
 ext4_expand_extra_isize_ea+0x12da/0x1ea0 fs/ext4/xattr.c:2831
 __ext4_expand_extra_isize+0x30d/0x400 fs/ext4/inode.c:6349
 ext4_try_to_expand_extra_isize fs/ext4/inode.c:6392 [inline]
 __ext4_mark_inode_dirty+0x45c/0x6e0 fs/ext4/inode.c:6470
 __ext4_unlink+0x631/0xab0 fs/ext4/namei.c:3282
 ext4_unlink+0x206/0x590 fs/ext4/namei.c:3312
 vfs_unlink+0x380/0x640 fs/namei.c:5369
 do_unlinkat+0x2cf/0x560 fs/namei.c:5439
 __do_sys_unlink fs/namei.c:5474 [inline]
 __se_sys_unlink fs/namei.c:5472 [inline]
 __x64_sys_unlink+0x47/0x50 fs/namei.c:5472
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff88800077a000
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 80 bytes inside of
 1024-byte region [ffff88800077a000, ffff88800077a400)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x778
head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x7ff00000000040(head|node=0|zone=0|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 007ff00000000040 ffff88801a441dc0 dead000000000122 0000000000000000
raw: 0000000000000000 0000000080080008 00000000f5000000 0000000000000000
head: 007ff00000000040 ffff88801a441dc0 dead000000000122 0000000000000000
head: 0000000000000000 0000000080080008 00000000f5000000 0000000000000000
head: 007ff00000000002 ffffea000001de01 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 2, migratetype Unmovable, gfp_mask 0x252800(GFP_NOWAIT|__GFP_NORETRY|__GFP_COMP|__GFP_THISNODE), pid 5873, tgid 5872 (syz.0.17), ts 160723892073, free_ts 160040949869
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x234/0x290 mm/page_alloc.c:1846
 prep_new_page mm/page_alloc.c:1854 [inline]
 get_page_from_freelist+0x2365/0x2440 mm/page_alloc.c:3915
 __alloc_pages_slowpath+0x30b/0xce0 mm/page_alloc.c:4741
 __alloc_frozen_pages_noprof+0x319/0x370 mm/page_alloc.c:5223
 alloc_slab_page mm/slub.c:3077 [inline]
 allocate_slab+0x7a/0x3b0 mm/slub.c:3248
 new_slab mm/slub.c:3302 [inline]
 ___slab_alloc+0xf2b/0x1960 mm/slub.c:4656
 __slab_alloc+0x65/0x100 mm/slub.c:4779
 __slab_alloc_node mm/slub.c:4855 [inline]
 slab_alloc_node mm/slub.c:5251 [inline]
 __do_kmalloc_node mm/slub.c:5656 [inline]
 __kmalloc_node_noprof+0x5d9/0x820 mm/slub.c:5663
 kmalloc_array_node_noprof include/linux/slab.h:1075 [inline]
 alloc_slab_obj_exts+0x3e/0x100 mm/slub.c:2123
 __memcg_slab_post_alloc_hook+0x330/0x730 mm/memcontrol.c:3197
 memcg_slab_post_alloc_hook mm/slub.c:2338 [inline]
 slab_post_alloc_hook mm/slub.c:4964 [inline]
 slab_alloc_node mm/slub.c:5263 [inline]
 __do_kmalloc_node mm/slub.c:5656 [inline]
 __kmalloc_node_track_caller_noprof+0x5f3/0x820 mm/slub.c:5764
 __kmemdup_nul mm/util.c:64 [inline]
 kstrdup+0x42/0x100 mm/util.c:84
 alloc_vfsmnt+0xeb/0x430 fs/namespace.c:302
 vfs_create_mount+0x69/0x320 fs/namespace.c:1184
 fc_mount fs/namespace.c:1202 [inline]
 do_new_mount_fc fs/namespace.c:3636 [inline]
 do_new_mount+0x390/0xa10 fs/namespace.c:3712
 do_mount fs/namespace.c:4035 [inline]
 __do_sys_mount fs/namespace.c:4224 [inline]
 __se_sys_mount+0x313/0x410 fs/namespace.c:4201
page last free pid 5862 tgid 5862 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 free_pages_prepare mm/page_alloc.c:1395 [inline]
 __free_frozen_pages+0xbc8/0xd30 mm/page_alloc.c:2943
 __slab_free+0x21b/0x2a0 mm/slub.c:6004
 qlink_free mm/kasan/quarantine.c:163 [inline]
 qlist_free_all+0x97/0x100 mm/kasan/quarantine.c:179
 kasan_quarantine_reduce+0x148/0x160 mm/kasan/quarantine.c:286
 __kasan_slab_alloc+0x22/0x80 mm/kasan/common.c:349
 kasan_slab_alloc include/linux/kasan.h:252 [inline]
 slab_post_alloc_hook mm/slub.c:4953 [inline]
 slab_alloc_node mm/slub.c:5263 [inline]
 kmem_cache_alloc_noprof+0x37d/0x710 mm/slub.c:5270
 getname_flags+0xb8/0x540 fs/namei.c:146
 getname include/linux/fs.h:2498 [inline]
 do_sys_openat2+0xbc/0x200 fs/open.c:1426
 do_sys_open fs/open.c:1436 [inline]
 __do_sys_openat fs/open.c:1452 [inline]
 __se_sys_openat fs/open.c:1447 [inline]
 __x64_sys_openat+0x138/0x170 fs/open.c:1447
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Memory state around the buggy address:
 ffff888000779f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff888000779f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88800077a000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                                                 ^
 ffff88800077a080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88800077a100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================


Tested on:

commit:         40fbbd64 Merge tag 'pull-fixes' of git://git.kernel.or..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16918392580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=72e765d013fc99c
dashboard link: https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

Note: no patches were applied.

Re: [syzbot] [ext4?] KASAN: out-of-bounds Read in ext4_xattr_set_entry

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com
Tested-by: syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com

Tested on:

commit:         40fbbd64 Merge tag 'pull-fixes' of git://git.kernel.or..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=154c931a580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=72e765d013fc99c
dashboard link: https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=118de184580000

Note: testing is done by a robot and is best-effort only.

Re: [PATCH] ext4: xattr: fix wrong search.here in clone_block

[Jan Kara]

Hello!

On Tue 16-12-25 19:34:55, Jinchao Wang wrote:
> syzbot reported a KASAN out-of-bounds Read in ext4_xattr_set_entry()[1].
> 
> When xattr_find_entry() returns -ENODATA, search.here still points to the
> position after the last valid entry. ext4_xattr_block_set() clones the xattr
> block because the original block maybe shared and must not be modified in
> place.
> 
> In the clone_block, search.here is recomputed unconditionally from the old
> offset, which may place it past search.first. This results in a negative
> reset size and an out-of-bounds memmove() in ext4_xattr_set_entry().
> 
> Fix this by initializing search.here correctly when search.not_found is set.
> 
> [1] https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1
> 
> Fixes: fd48e9acdf2 (ext4: Unindent codeblock in ext4_xattr_block_set)
> Cc: stable@vger.kernel.org
> Reported-by: syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com
> Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>

Thanks for the patch! But I think the problem must be somewhere else. When
a search ends without success (-ENODATA error), s->here points to the
4-byte zeroed word inside xattr space that terminates the part with xattr
headers. If I understand correctly the expression which overflows is:

size_t rest = (void *)last - (void *)here + sizeof(__u32);

in ext4_xattr_set_entry(). And I don't see how 'here' can be greater than
'last' which should be pointing to the very same 4-byte zeroed word. The
fact that 'here' and 'last' are not equal is IMO the problem which needs
debugging and it indicates there's something really fishy going on with the
xattr block we work with. The block should be freshly allocated one as far
as I'm checking the disk image (as the 'file1' file doesn't have xattr
block in the original image).

								Honza

> diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
> index 2e02efbddaac..cc30abeb7f30 100644
> --- a/fs/ext4/xattr.c
> +++ b/fs/ext4/xattr.c
> @@ -1980,7 +1980,10 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
>  			goto cleanup;
>  		s->first = ENTRY(header(s->base)+1);
>  		header(s->base)->h_refcount = cpu_to_le32(1);
> -		s->here = ENTRY(s->base + offset);
> +		if (s->not_found)
> +			s->here = s->first;
> +		else
> +			s->here = ENTRY(s->base + offset);
>  		s->end = s->base + bs->bh->b_size;
>  
>  		/*
> -- 
> 2.43.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] ext4: xattr: fix wrong search.here in clone_block

[Jinchao Wang]

On Wed, Dec 17, 2025 at 12:30:15PM +0100, Jan Kara wrote:
> Hello!
> 
> On Tue 16-12-25 19:34:55, Jinchao Wang wrote:
> > syzbot reported a KASAN out-of-bounds Read in ext4_xattr_set_entry()[1].
> > 
> > When xattr_find_entry() returns -ENODATA, search.here still points to the
> > position after the last valid entry. ext4_xattr_block_set() clones the xattr
> > block because the original block maybe shared and must not be modified in
> > place.
> > 
> > In the clone_block, search.here is recomputed unconditionally from the old
> > offset, which may place it past search.first. This results in a negative
> > reset size and an out-of-bounds memmove() in ext4_xattr_set_entry().
> > 
> > Fix this by initializing search.here correctly when search.not_found is set.
> > 
> > [1] https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1
> > 
> > Fixes: fd48e9acdf2 (ext4: Unindent codeblock in ext4_xattr_block_set)
> > Cc: stable@vger.kernel.org
> > Reported-by: syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com
> > Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
> 
> Thanks for the patch! But I think the problem must be somewhere else. 
The first syzbot test report was run without the patch applied,
which caused confusion.
The correct usage and report show that this patch fixes the crash:
https://lore.kernel.org/all/20251216123945.391988-2-wangjinchao600@gmail.com/
https://lore.kernel.org/all/6941580e.a70a0220.33cd7b.013d.GAE@google.com/

>When
> a search ends without success (-ENODATA error), s->here points to the
> 4-byte zeroed word inside xattr space that terminates the part with xattr
> headers. If I understand correctly the expression which overflows is:
> 
> size_t rest = (void *)last - (void *)here + sizeof(__u32);
> 
Yes, you are right about all of the above.

> in ext4_xattr_set_entry(). And I don't see how 'here' can be greater than
> 'last' which should be pointing to the very same 4-byte zeroed word. The
> fact that 'here' and 'last' are not equal is IMO the problem which needs
> debugging and it indicates there's something really fishy going on with the
> xattr block we work with. The block should be freshly allocated one as far
> as I'm checking the disk image (as the 'file1' file doesn't have xattr
> block in the original image).

I traced the crash path and find how this hapens:

entry_SYSCALL_64
...
ext4_xattr_move_to_block
  ext4_xattr_block_find (){
    error = xattr_find_entry(inode, &bs->s.here, ...); // bs->s.here updated 
                                                       // to ENTRY(header(s->first)+1);
    if (error && error != -ENODATA)
      return error;
    bs->s.not_found = error; // and returned to the caller
  }
  ext4_xattr_block_set (bs) {
    s = bs->s;
    offset = (char *)s->here - bs->bh->b_data; // bs->bh->b_data == bs->s.base
                                               // offset = ENTRY(header(s->first)+1) - s.base
                                               // leads to wrong offset
    clone_block: {
	s->base = kmemdup(BHDR(bs->bh), bs->bh->b_size, GFP_NOFS);
	s->first = ENTRY(header(s->base)+1);
	s->here = ENTRY(s->base + offset); // wrong s->here
    }
    ext4_xattr_set_entry (s) {
      last = s->first; // last < here
      rest = (void *)last - (void *)here + sizeof(__u32); // negative rest
      memmove((void *)here + size, here, rest); // crash
    }
  }
> 
> 								Honza
> 
> > diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
> > index 2e02efbddaac..cc30abeb7f30 100644
> > --- a/fs/ext4/xattr.c
> > +++ b/fs/ext4/xattr.c
> > @@ -1980,7 +1980,10 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
> >  			goto cleanup;
> >  		s->first = ENTRY(header(s->base)+1);
> >  		header(s->base)->h_refcount = cpu_to_le32(1);
> > -		s->here = ENTRY(s->base + offset);
> > +		if (s->not_found)
> > +			s->here = s->first;
> > +		else
> > +			s->here = ENTRY(s->base + offset);
> >  		s->end = s->base + bs->bh->b_size;
> >  
> >  		/*
> > -- 
> > 2.43.0
> > 
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR

Re: [PATCH] ext4: xattr: fix wrong search.here in clone_block

[Jan Kara]

On Thu 18-12-25 09:40:36, Jinchao Wang wrote:
> On Wed, Dec 17, 2025 at 12:30:15PM +0100, Jan Kara wrote:
> > Hello!
> > 
> > On Tue 16-12-25 19:34:55, Jinchao Wang wrote:
> > > syzbot reported a KASAN out-of-bounds Read in ext4_xattr_set_entry()[1].
> > > 
> > > When xattr_find_entry() returns -ENODATA, search.here still points to the
> > > position after the last valid entry. ext4_xattr_block_set() clones the xattr
> > > block because the original block maybe shared and must not be modified in
> > > place.
> > > 
> > > In the clone_block, search.here is recomputed unconditionally from the old
> > > offset, which may place it past search.first. This results in a negative
> > > reset size and an out-of-bounds memmove() in ext4_xattr_set_entry().
> > > 
> > > Fix this by initializing search.here correctly when search.not_found is set.
> > > 
> > > [1] https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1
> > > 
> > > Fixes: fd48e9acdf2 (ext4: Unindent codeblock in ext4_xattr_block_set)
> > > Cc: stable@vger.kernel.org
> > > Reported-by: syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com
> > > Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
> > 
> > Thanks for the patch! But I think the problem must be somewhere else. 
> The first syzbot test report was run without the patch applied,
> which caused confusion.
> The correct usage and report show that this patch fixes the crash:
> https://lore.kernel.org/all/20251216123945.391988-2-wangjinchao600@gmail.com/
> https://lore.kernel.org/all/6941580e.a70a0220.33cd7b.013d.GAE@google.com/

I was not arguing that your patch doesn't fix this syzbot issue. Just that
I don't understand how what you describe can happen and thus I'm not sure
whether the fix is really the best one...

> > in ext4_xattr_set_entry(). And I don't see how 'here' can be greater than
> > 'last' which should be pointing to the very same 4-byte zeroed word. The
> > fact that 'here' and 'last' are not equal is IMO the problem which needs
> > debugging and it indicates there's something really fishy going on with the
> > xattr block we work with. The block should be freshly allocated one as far
> > as I'm checking the disk image (as the 'file1' file doesn't have xattr
> > block in the original image).
> 
> I traced the crash path and find how this hapens:

Thanks for sharing the details!

> entry_SYSCALL_64
> ...
> ext4_xattr_move_to_block
>   ext4_xattr_block_find (){
>     error = xattr_find_entry(inode, &bs->s.here, ...); // bs->s.here updated 
>                                                        // to ENTRY(header(s->first)+1);
>     if (error && error != -ENODATA)
>       return error;
>     bs->s.not_found = error; // and returned to the caller
>   }
>   ext4_xattr_block_set (bs) {
>     s = bs->s;
>     offset = (char *)s->here - bs->bh->b_data; // bs->bh->b_data == bs->s.base
>                                                // offset = ENTRY(header(s->first)+1) - s.base
>                                                // leads to wrong offset

Why do you think the offset is wrong here? The offset is correct AFAICS -
it will be the offset of the 0 word from the beginning of xattr block. I
have run the reproducer myself and as I guessed in my previous email the
real problem is that someone modifies the xattr block between we compute
the offset here and the moment we call kmemdup() in clone_block. Thus the
computation of 'last' in ext4_xattr_set_entry() yields a different result
that what we saw in ext4_xattr_block_set(). The block modification happens
because the xattr block - block 33 is used for it - is also referenced from
file3 (but it was marked as unused in the block bitmap and so xattr block
got placed there).

So your patch was fixing the problem only by chance and slightly different
syzbot reproducer (overwriting the block 33 with a different contents)
would trigger the crash again.

So far I wasn't able to figure out how exactly the block 33 got zeroed out
but with corrupted filesystem it can happen in principle rather easily. The
question is how we can possibly fix this because this is one of the nastier
cases of fs corrution to deal with. The overhead of re-verifying fs
metadata each time we relock the buffer is just too big... So far no great
ideas for this.

								Honza

>     clone_block: {
> 	s->base = kmemdup(BHDR(bs->bh), bs->bh->b_size, GFP_NOFS);
> 	s->first = ENTRY(header(s->base)+1);
> 	s->here = ENTRY(s->base + offset); // wrong s->here
>     }
>     ext4_xattr_set_entry (s) {
>       last = s->first; // last < here
>       rest = (void *)last - (void *)here + sizeof(__u32); // negative rest
>       memmove((void *)here + size, here, rest); // crash
>     }
>   }
> > 
> > 								Honza
> > 
> > > diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
> > > index 2e02efbddaac..cc30abeb7f30 100644
> > > --- a/fs/ext4/xattr.c
> > > +++ b/fs/ext4/xattr.c
> > > @@ -1980,7 +1980,10 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
> > >  			goto cleanup;
> > >  		s->first = ENTRY(header(s->base)+1);
> > >  		header(s->base)->h_refcount = cpu_to_le32(1);
> > > -		s->here = ENTRY(s->base + offset);
> > > +		if (s->not_found)
> > > +			s->here = s->first;
> > > +		else
> > > +			s->here = ENTRY(s->base + offset);
> > >  		s->end = s->base + bs->bh->b_size;
> > >  
> > >  		/*
> > > -- 
> > > 2.43.0
> > > 
> > -- 
> > Jan Kara <jack@suse.com>
> > SUSE Labs, CR
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] ext4: xattr: fix wrong search.here in clone_block

[Jinchao Wang]

On Thu, Dec 18, 2025 at 04:39:08PM +0100, Jan Kara wrote:
> On Thu 18-12-25 09:40:36, Jinchao Wang wrote:
> > On Wed, Dec 17, 2025 at 12:30:15PM +0100, Jan Kara wrote:
> > > Hello!
> > > 
> > > On Tue 16-12-25 19:34:55, Jinchao Wang wrote:
> > > > syzbot reported a KASAN out-of-bounds Read in ext4_xattr_set_entry()[1].
> > > > 
> > > > When xattr_find_entry() returns -ENODATA, search.here still points to the
> > > > position after the last valid entry. ext4_xattr_block_set() clones the xattr
> > > > block because the original block maybe shared and must not be modified in
> > > > place.
> > > > 
> > > > In the clone_block, search.here is recomputed unconditionally from the old
> > > > offset, which may place it past search.first. This results in a negative
> > > > reset size and an out-of-bounds memmove() in ext4_xattr_set_entry().
> > > > 
> > > > Fix this by initializing search.here correctly when search.not_found is set.
> > > > 
> > > > [1] https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1
> > > > 
> > > > Fixes: fd48e9acdf2 (ext4: Unindent codeblock in ext4_xattr_block_set)
> > > > Cc: stable@vger.kernel.org
> > > > Reported-by: syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com
> > > > Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
> > > 
> > > Thanks for the patch! But I think the problem must be somewhere else. 
> > The first syzbot test report was run without the patch applied,
> > which caused confusion.
> > The correct usage and report show that this patch fixes the crash:
> > https://lore.kernel.org/all/20251216123945.391988-2-wangjinchao600@gmail.com/
> > https://lore.kernel.org/all/6941580e.a70a0220.33cd7b.013d.GAE@google.com/
> 
> I was not arguing that your patch doesn't fix this syzbot issue. Just that
> I don't understand how what you describe can happen and thus I'm not sure
> whether the fix is really the best one...
> 
> > > in ext4_xattr_set_entry(). And I don't see how 'here' can be greater than
> > > 'last' which should be pointing to the very same 4-byte zeroed word. The
> > > fact that 'here' and 'last' are not equal is IMO the problem which needs
> > > debugging and it indicates there's something really fishy going on with the
> > > xattr block we work with. The block should be freshly allocated one as far
> > > as I'm checking the disk image (as the 'file1' file doesn't have xattr
> > > block in the original image).
> > 
> > I traced the crash path and find how this hapens:
> 
> Thanks for sharing the details!
> 
> > entry_SYSCALL_64
> > ...
> > ext4_xattr_move_to_block
> >   ext4_xattr_block_find (){
> >     error = xattr_find_entry(inode, &bs->s.here, ...); // bs->s.here updated 
> >                                                        // to ENTRY(header(s->first)+1);
> >     if (error && error != -ENODATA)
> >       return error;
> >     bs->s.not_found = error; // and returned to the caller
> >   }
> >   ext4_xattr_block_set (bs) {
> >     s = bs->s;
> >     offset = (char *)s->here - bs->bh->b_data; // bs->bh->b_data == bs->s.base
> >                                                // offset = ENTRY(header(s->first)+1) - s.base
> >                                                // leads to wrong offset
> 
> Why do you think the offset is wrong here? The offset is correct AFAICS -
> it will be the offset of the 0 word from the beginning of xattr block. I
> have run the reproducer myself and as I guessed in my previous email the
> real problem is that someone modifies the xattr block between we compute
> the offset here and the moment we call kmemdup() in clone_block. Thus the
> computation of 'last' in ext4_xattr_set_entry() yields a different result
> that what we saw in ext4_xattr_block_set(). The block modification happens
> because the xattr block - block 33 is used for it - is also referenced from
> file3 (but it was marked as unused in the block bitmap and so xattr block
> got placed there).
> 
> So your patch was fixing the problem only by chance and slightly different
> syzbot reproducer (overwriting the block 33 with a different contents)
> would trigger the crash again.
> 
> So far I wasn't able to figure out how exactly the block 33 got zeroed out
> but with corrupted filesystem it can happen in principle rather easily. The
> question is how we can possibly fix this because this is one of the nastier
> cases of fs corrution to deal with. The overhead of re-verifying fs
> metadata each time we relock the buffer is just too big... So far no great
> ideas for this.
> 
> 								Honza
> 

Baokun explained part of the process in the kernel space.
https://lore.kernel.org/all/d62a25e9-04de-4309-98d1-22a4f9b5bb49@huawei.com/

I analysed syz-reproducer and add some userspace details:

- original filesystem state
  - file1:
    - inode 15 with File ACL block 33
  - file2:
    - inode 16 with data blocks 27–35
- actions
  - syscall(__NR_creat, "file2")
  - syscall(__NR_unlink, "file1")  // panic happens here

The original filesystem state is already corrupted, with block 33 beging
referenced both as an xattr block and as file data.