All of lore.kernel.org
 help / color / mirror / Atom feed
From: syzbot <syzbot+5f7f0caf9979e9d09ff8@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
	 yun.zhou@windriver.com
Subject: Re: [syzbot] [jfs?] UBSAN: array-index-out-of-bounds in dtInsertEntry
Date: Tue, 18 Nov 2025 06:35:03 -0800	[thread overview]
Message-ID: <691c8417.a70a0220.3124cb.00ca.GAE@google.com> (raw)
In-Reply-To: <SJ5PPF2F7FC4EE6D578FC2713AE8DA93A359FD6A@SJ5PPF2F7FC4EE6.namprd11.prod.outlook.com>

Hello,

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

read_mapping_page failed!
ERROR: (device loop0): txCommit: 
read_mapping_page failed!
ERROR: (device loop0): txCommit: 
==================================================================
BUG: KASAN: slab-out-of-bounds in dtSplitPage+0x121b/0x38c0 fs/jfs/jfs_dtree.c:-1
Read of size 1 at addr ffff888060f891dd by task syz.0.16/6471

CPU: 0 UID: 0 PID: 6471 Comm: syz.0.16 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
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
 dtSplitPage+0x121b/0x38c0 fs/jfs/jfs_dtree.c:-1
 dtSplitUp fs/jfs/jfs_dtree.c:1092 [inline]
 dtInsert+0x100c/0x5d10 fs/jfs/jfs_dtree.c:871
 jfs_mkdir+0x6ec/0xa70 fs/jfs/namei.c:270
 vfs_mkdir+0x306/0x510 fs/namei.c:4453
 do_mkdirat+0x247/0x590 fs/namei.c:4486
 __do_sys_mkdirat fs/namei.c:4503 [inline]
 __se_sys_mkdirat fs/namei.c:4501 [inline]
 __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4501
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f8cecf8d1d7
Code: 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 02 01 00 00 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:00007f8cede76e68 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 00007f8cede76ef0 RCX: 00007f8cecf8d1d7
RDX: 00000000000001ff RSI: 0000200000000040 RDI: 00000000ffffff9c
RBP: 0000200000000140 R08: 00002000000000c0 R09: 0000000000000000
R10: 0000200000000140 R11: 0000000000000246 R12: 0000200000000040
R13: 00007f8cede76eb0 R14: 0000000000000000 R15: 0000000000000000
 </TASK>

Allocated by task 6471:
 kasan_save_stack mm/kasan/common.c:56 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:77
 unpoison_slab_object mm/kasan/common.c:342 [inline]
 __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:368
 kasan_slab_alloc include/linux/kasan.h:252 [inline]
 slab_post_alloc_hook mm/slub.c:4978 [inline]
 slab_alloc_node mm/slub.c:5288 [inline]
 kmem_cache_alloc_lru_noprof+0x35d/0x6d0 mm/slub.c:5307
 jfs_alloc_inode+0x28/0x70 fs/jfs/super.c:105
 alloc_inode+0x6a/0x1b0 fs/inode.c:346
 iget_locked+0x106/0x580 fs/inode.c:1445
 jfs_iget+0x24/0x470 fs/jfs/inode.c:29
 jfs_lookup+0x1c5/0x380 fs/jfs/namei.c:1469
 __lookup_slow+0x297/0x3d0 fs/namei.c:1816
 lookup_slow+0x53/0x70 fs/namei.c:1833
 walk_component+0x2d2/0x400 fs/namei.c:2151
 lookup_last fs/namei.c:2652 [inline]
 path_lookupat+0x163/0x430 fs/namei.c:2676
 filename_lookup+0x212/0x570 fs/namei.c:2705
 user_path_at+0x3a/0x60 fs/namei.c:3215
 __do_sys_chdir fs/open.c:561 [inline]
 __se_sys_chdir+0x91/0x280 fs/open.c:555
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff888060f88928
 which belongs to the cache jfs_ip of size 2216
The buggy address is located 13 bytes to the right of
 allocated 2216-byte region [ffff888060f88928, ffff888060f891d0)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x60f88
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
memcg:ffff888077ec2e01
flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000040 ffff88801e397280 dead000000000122 0000000000000000
raw: 0000000000000000 00000000800d000d 00000000f5000000 ffff888077ec2e01
head: 00fff00000000040 ffff88801e397280 dead000000000122 0000000000000000
head: 0000000000000000 00000000800d000d 00000000f5000000 ffff888077ec2e01
head: 00fff00000000003 ffffea000183e201 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Reclaimable, gfp_mask 0xd2050(__GFP_RECLAIMABLE|__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 6471, tgid 6470 (syz.0.16), ts 129317552975, free_ts 22248192864
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1850
 prep_new_page mm/page_alloc.c:1858 [inline]
 get_page_from_freelist+0x2356/0x2430 mm/page_alloc.c:3884
 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5183
 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416
 alloc_slab_page mm/slub.c:3059 [inline]
 allocate_slab+0x96/0x350 mm/slub.c:3232
 new_slab mm/slub.c:3286 [inline]
 ___slab_alloc+0xf56/0x1990 mm/slub.c:4655
 __slab_alloc+0x65/0x100 mm/slub.c:4778
 __slab_alloc_node mm/slub.c:4854 [inline]
 slab_alloc_node mm/slub.c:5276 [inline]
 kmem_cache_alloc_lru_noprof+0x3ef/0x6d0 mm/slub.c:5307
 jfs_alloc_inode+0x28/0x70 fs/jfs/super.c:105
 alloc_inode+0x6a/0x1b0 fs/inode.c:346
 iget_locked+0x106/0x580 fs/inode.c:1445
 jfs_iget+0x24/0x470 fs/jfs/inode.c:29
 jfs_fill_super+0x8ad/0xd80 fs/jfs/super.c:547
 get_tree_bdev_flags+0x40e/0x4d0 fs/super.c:1698
 vfs_get_tree+0x92/0x2b0 fs/super.c:1758
 fc_mount fs/namespace.c:1199 [inline]
 do_new_mount_fc fs/namespace.c:3642 [inline]
 do_new_mount+0x302/0xa10 fs/namespace.c:3718
page last free pid 1 tgid 1 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 free_pages_prepare mm/page_alloc.c:1394 [inline]
 __free_frozen_pages+0xbb1/0xd20 mm/page_alloc.c:2906
 __free_pages mm/page_alloc.c:5302 [inline]
 free_contig_range+0x1bd/0x4a0 mm/page_alloc.c:7146
 destroy_args+0x69/0x660 mm/debug_vm_pgtable.c:958
 debug_vm_pgtable+0x39f/0x3b0 mm/debug_vm_pgtable.c:1345
 do_one_initcall+0x236/0x820 init/main.c:1283
 do_initcall_level+0x104/0x190 init/main.c:1345
 do_initcalls+0x59/0xa0 init/main.c:1361
 kernel_init_freeable+0x334/0x4b0 init/main.c:1593
 kernel_init+0x1d/0x1d0 init/main.c:1483
 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Memory state around the buggy address:
 ffff888060f89080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff888060f89100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff888060f89180: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
                                                    ^
 ffff888060f89200: fc fc fc fc fc fc fc fc fc fc 00 00 00 00 00 00
 ffff888060f89280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================


Tested on:

commit:         e7c375b1 Merge tag 'vfs-6.18-rc7.fixes' of gitolite.ke..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10ca3914580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=38deb25bbc2fa41e
dashboard link: https://syzkaller.appspot.com/bug?extid=5f7f0caf9979e9d09ff8
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=110df212580000


       reply	other threads:[~2025-11-18 14:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <SJ5PPF2F7FC4EE6D578FC2713AE8DA93A359FD6A@SJ5PPF2F7FC4EE6.namprd11.prod.outlook.com>
2025-11-18 14:35 ` syzbot [this message]
2024-10-10 13:13 UBSAN: array-index-out-of-bounds in dtInsertEntry Ghanshyam Agrawal
2024-10-10 13:43 ` [syzbot] [jfs?] " syzbot
  -- strict thread matches above, loose matches on Subject: below --
2024-10-03 19:10 syzbot
2024-10-10 11:57 ` syzbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=691c8417.a70a0220.3124cb.00ca.GAE@google.com \
    --to=syzbot+5f7f0caf9979e9d09ff8@syzkaller.appspotmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=yun.zhou@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.