From: CJ <firefly0158@163.com>
To: shaggy@kernel.org, yun.zhou@windriver.com, kees@kernel.org
Cc: jfs-discussion@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: [BUG] jfs: WARNING in dbAdjTree
Date: Tue, 15 Sep 2026 14:59:28 +0800 (CST) [thread overview]
Message-ID: <1ad18b52.5cab.1a0a3dd0d16.Coremail.firefly0158@163.com> (raw)
Hi,
I am reporting a WARNING in the JFS dmap tree maintenance path, triggered by a
syzkaller reproducer that mounts a crafted JFS image. The issue is reproducible
with HEAD commit cee9395acd8043be0644b25c34bfa86623f2b935 (v7.3-rc1, Linux
7.3.0-rc1).
The reproducer mounts a crafted JFS filesystem image on a loop device and frees
blocks, which makes the allocator update the dmap tree. The failing context is
the JFS commit thread jfsCommit, not the syscall task.
The console shows "WARNING: fs/jfs/jfs_dmap.c:2962 at dbAdjTree+0x307/0x3f0" with
RIP in dbAdjTree. On the kernel where this was first reported the same path was
reported by UBSAN as an array-index-out-of-bounds at fs/jfs/jfs_dmap.c:2848,
where index 1621 was out of range for a s8[1365] array, so the two kernels expose
the same dmap-tree invariant violation as an out-of-bounds index on the older one
and a warning on v7.3-rc1. Because the failure classes differ, I am describing
this as a likely recurrence rather than an identical splat.
One possible cause is that while walking up the dmap tree the code computes a
parent or sibling index from the crafted image's tree control data without
checking it against the tree's real size, so the adjustment is applied at an
invalid index. This looks like a missing range check on dmap tree indices. I am
reporting the warning and the path as observed.
This appears to be a recurrence of the syzbot issue whose external id is
cffee4987ee15d116a32. It remains reproducible on v7.3-rc1.
Reproducer:
syz reproducer: https://pastebin.com/raw/fGv0afiE
console output: https://pastebin.com/raw/4AKf8eft
kernel config: https://pastebin.com/raw/HpHefATi
Kernel:
HEAD commit: cee9395acd8043be0644b25c34bfa86623f2b935
git tree: upstream (linux.git), tested through the v7.3-rc1 annotated tag object
e5e04726cdd043e309677071ab1b65a4b18f422b
kernel version: 7.3.0-rc1 #1 PREEMPT(full)
tested tag: v7.3-rc1 (Linux 7.3-rc1, 2026-08-30)
Let me know if you need more details or testing.
Best regards,
Changjian
reply other threads:[~2026-09-15 6:59 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=1ad18b52.5cab.1a0a3dd0d16.Coremail.firefly0158@163.com \
--to=firefly0158@163.com \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shaggy@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®