From: syzbot <syzbot+8e638a3726a11c61829e@syzkaller.appspotmail.com>
To: jfs-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org, shaggy@kernel.org,
syzkaller-bugs@googlegroups.com
Subject: [syzbot] [jfs?] KASAN: slab-use-after-free Read in txUnlock (3)
Date: Sun, 19 Jul 2026 18:38:34 -0700 [thread overview]
Message-ID: <6a5d7c1a.42649fcc.6186.007d.GAE@google.com> (raw)
Hello,
syzbot found the following issue on:
HEAD commit: fce2dfa773ce Merge tag 'v7.2-rc3-smb3-client-fixes' of git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12fc6cb9580000
kernel config: https://syzkaller.appspot.com/x/.config?x=20c9876b0f77b546
dashboard link: https://syzkaller.appspot.com/bug?extid=8e638a3726a11c61829e
compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-fce2dfa7.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/1c8b7734ea9f/vmlinux-fce2dfa7.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a3b9e83087a5/bzImage-fce2dfa7.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8e638a3726a11c61829e@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-use-after-free in txUnlock+0x951/0xde0 fs/jfs/jfs_txnmgr.c:927
Read of size 2 at addr ffff888031a86c98 by task jfsCommit/108
CPU: 0 UID: 0 PID: 108 Comm: jfsCommit Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description+0x55/0x1e0 mm/kasan/report.c:378
print_report+0x58/0x70 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
txUnlock+0x951/0xde0 fs/jfs/jfs_txnmgr.c:927
txLazyCommit fs/jfs/jfs_txnmgr.c:2684 [inline]
jfs_lazycommit+0x59f/0xac0 fs/jfs/jfs_txnmgr.c:2735
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Allocated by task 5328:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
unpoison_slab_object mm/kasan/common.c:340 [inline]
__kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4612 [inline]
slab_alloc_node mm/slub.c:4945 [inline]
kmem_cache_alloc_noprof+0x2a0/0x5f0 mm/slub.c:4959
mempool_alloc_noprof+0x1bf/0x300 mm/mempool.c:559
alloc_metapage fs/jfs/jfs_metapage.c:264 [inline]
__get_metapage+0x4ed/0xdf0 fs/jfs/jfs_metapage.c:761
diWrite+0x401/0x1f60 fs/jfs/jfs_imap.c:639
txCommit+0x83a/0x54a0 fs/jfs/jfs_txnmgr.c:1257
__jfs_xattr_set+0x10e/0x170 fs/jfs/xattr.c:943
__vfs_setxattr+0x442/0x480 fs/xattr.c:223
__vfs_setxattr_noperm+0x12a/0x660 fs/xattr.c:257
vfs_setxattr+0x163/0x360 fs/xattr.c:344
do_setxattr fs/xattr.c:662 [inline]
filename_setxattr+0x296/0x630 fs/xattr.c:690
path_setxattrat+0x408/0x450 fs/xattr.c:734
__do_sys_setxattr fs/xattr.c:768 [inline]
__se_sys_setxattr fs/xattr.c:764 [inline]
__x64_sys_setxattr+0xbc/0xe0 fs/xattr.c:764
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 75:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2705 [inline]
slab_free mm/slub.c:6405 [inline]
kmem_cache_free+0x182/0x650 mm/slub.c:6532
mempool_free+0xec/0x130 mm/mempool.c:704
free_metapage fs/jfs/jfs_metapage.c:280 [inline]
metapage_release_folio+0x462/0x590 fs/jfs/jfs_metapage.c:637
shrink_folio_list+0x2364/0x5330 mm/vmscan.c:1463
evict_folios+0x3821/0x4b40 mm/vmscan.c:4835
try_to_shrink_lruvec+0xb4f/0xed0 mm/vmscan.c:4983
shrink_one+0x233/0x730 mm/vmscan.c:5024
shrink_many mm/vmscan.c:5087 [inline]
lru_gen_shrink_node mm/vmscan.c:5165 [inline]
shrink_node+0x3303/0x3b60 mm/vmscan.c:6154
kswapd_shrink_node mm/vmscan.c:7008 [inline]
balance_pgdat mm/vmscan.c:7186 [inline]
kswapd+0x17b6/0x31c0 mm/vmscan.c:7462
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
The buggy address belongs to the object at ffff888031a86c98
which belongs to the cache jfs_mp of size 184
The buggy address is located 0 bytes inside of
freed 184-byte region [ffff888031a86c98, ffff888031a86d50)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x31a86
flags: 0x4fff00000000000(node=1|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 04fff00000000000 ffff8880316b6dc0 dead000000000122 0000000000000000
raw: 0000000000000000 0000000800100010 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 1, tgid 1 (swapper/0), ts 9012459893, free_ts 0
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x1f9/0x250 mm/page_alloc.c:1859
prep_new_page mm/page_alloc.c:1867 [inline]
get_page_from_freelist+0x21fa/0x2270 mm/page_alloc.c:3946
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5304
alloc_slab_page mm/slub.c:3294 [inline]
allocate_slab+0x79/0x5e0 mm/slub.c:3408
new_slab mm/slub.c:3454 [inline]
refill_objects+0x2d5/0x350 mm/slub.c:7338
refill_sheaf mm/slub.c:2832 [inline]
__pcs_replace_empty_main+0x2bf/0x6b0 mm/slub.c:4703
alloc_from_pcs mm/slub.c:4801 [inline]
slab_alloc_node mm/slub.c:4933 [inline]
kmem_cache_alloc_noprof+0x382/0x5f0 mm/slub.c:4959
mempool_init_node+0x1f4/0x4f0 mm/mempool.c:259
mempool_create_node_noprof+0xb8/0x150 mm/mempool.c:323
metapage_init+0xed/0x150 fs/jfs/jfs_metapage.c:293
init_jfs_fs+0xfd/0x4e0 fs/jfs/super.c:969
do_one_initcall+0x250/0x870 init/main.c:1347
do_initcall_level+0x10a/0x1a0 init/main.c:1409
do_initcalls+0x59/0xa0 init/main.c:1425
kernel_init_freeable+0x29d/0x3e0 init/main.c:1658
kernel_init+0x1d/0x1d0 init/main.c:1548
page_owner free stack trace missing
Memory state around the buggy address:
ffff888031a86b80: fc fc fc fc fa fb fb fb fb fb fb fb fb fb fb fb
ffff888031a86c00: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
>ffff888031a86c80: fc fc fc fa fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888031a86d00: fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc
ffff888031a86d80: fc fc fa fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
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 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
reply other threads:[~2026-07-20 1:38 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=6a5d7c1a.42649fcc.6186.007d.GAE@google.com \
--to=syzbot+8e638a3726a11c61829e@syzkaller.appspotmail.com \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=shaggy@kernel.org \
--cc=syzkaller-bugs@googlegroups.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.