mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: CJ <firefly0158@163.com>
To: shaggy@kernel.org, yun.zhou@windriver.com, mjguzik@gmail.com,
	brauner@kernel.org, ssrane_b23@ee.vjti.ac.in
Cc: jfs-discussion@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: [BUG] jfs: kernel BUG in txUnlock at fs/jfs/jfs_txnmgr.c
Date: Mon, 14 Sep 2026 15:48:06 +0800 (CST)	[thread overview]
Message-ID: <57a2fc08.6fac.1a09ee33943.Coremail.firefly0158@163.com> (raw)

Hi,


I am reporting a kernel BUG in the JFS transaction manager, 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
performs file operations that force transaction commits on it.  The failing
context is the JFS commit thread jfsCommit, not the syscall task.


The console shows "kernel BUG at fs/jfs/jfs_txnmgr.c:933!" with an
invalid-opcode Oops and RIP in txUnlock.  The assertion at that site is
assert(mp->nohomeok > 0): the unlock path requires the transaction block to
still be pinned by the current task.


One possible cause is that the crafted image drives a commit path that returns
early, so the nohomeok reference on the transaction block is dropped before
txUnlock runs and the counter no longer reflects the block's state.  This looks
like a lifetime/reference-counting problem in the transaction manager rather
than a bounds problem, reached only with inconsistent on-disk metadata.  I am
reporting the assertion and the path as observed.


This appears to be a recurrence of the syzbot issue whose external id is
3c3866c71da45ef61201.  It remains reproducible on v7.3-rc1.


Reproducer:

syz reproducer: https://pastebin.com/raw/nMHHaQgp

console output: https://pastebin.com/raw/z6Aq4my6

kernel config: https://pastebin.com/raw/wDBHjUBC


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-14  7:48 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=57a2fc08.6fac.1a09ee33943.Coremail.firefly0158@163.com \
    --to=firefly0158@163.com \
    --cc=brauner@kernel.org \
    --cc=jfs-discussion@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjguzik@gmail.com \
    --cc=shaggy@kernel.org \
    --cc=ssrane_b23@ee.vjti.ac.in \
    --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®