From: CJ <firefly0158@163.com>
To: dwmw2@infradead.org, richard@nod.at
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: [BUG] jffs2: kernel BUG in jffs2_del_ino_cache
Date: Tue, 15 Sep 2026 14:39:39 +0800 (CST) [thread overview]
Message-ID: <23469bd6.56e9.1a0a3caead6.Coremail.firefly0158@163.com> (raw)
Hi,
I am reporting a kernel BUG in the jffs2 inode cache handling, triggered by a
syzkaller reproducer. The issue is reproducible with HEAD commit
cee9395acd8043be0644b25c34bfa86623f2b935 (v7.3-rc1, Linux 7.3.0-rc1).
The reproducer mounts devtmpfs, mounts the jffs2 filesystem found on
/dev/mtdblock0, and then sets a trusted.overlay.redirect extended attribute on
the mount point. No crafted image is uploaded by the reproducer; the trigger is
the attribute operation on the jffs2 mount.
The console shows "kernel BUG at fs/jffs2/nodelist.c:462!" with an
invalid-opcode Oops and RIP in jffs2_del_ino_cache. The path reaches it from
jffs2_do_clear_inode during inode eviction, when the inode cache entry is being
removed while the filesystem is still holding references related to the
attribute operation.
One possible cause is that the extended-attribute operation leaves an inode with
an unexpected cache state, so the removal path takes a branch that asserts the
inode is present in the cache list when it is not (or is present twice). This
looks like a state-management problem in the jffs2 inode cache rather than a
bounds error. I am reporting the assertion and the path as observed.
This appears to be a recurrence of the syzbot issue whose external id is
93f6bfed6a4a702b48cc. It remains reproducible on v7.3-rc1.
Reproducer:
syz reproducer:
mkdirat(0xffffffffffffff9c, &(0x7f0000000000)='./dev\x00', 0x1ff)
mount(0x0, &(0x7f0000000000)='./dev\x00', &(0x7f0000000100)='devtmpfs\x00', 0x0, 0x0)
mkdirat(0xffffffffffffff9c, &(0x7f0000000200)='./mnt\x00', 0x1ff)
mount(&(0x7f0000000300)=@filename='./dev/mtdblock0\x00', &(0x7f0000000200)='./mnt\x00', &(0x7f0000000400)='jffs2\x00', 0x0, 0x0)
lsetxattr$trusted_overlay_redirect(&(0x7f0000000040)='./mnt\x00', &(0x7f0000000080), 0x0, 0x0, 0x0)
console output: https://pastebin.com/raw/wfCKUiUY
kernel config: https://pastebin.com/raw/1TiKKS9a
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:40 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=23469bd6.56e9.1a0a3caead6.Coremail.firefly0158@163.com \
--to=firefly0158@163.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/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®