From: Greg Ociepka <greg@ferrisoft.com>
To: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: Christian Brauner <brauner@kernel.org>,
Yalagada Pavan Kumar <pavankumaryalagada@gmail.com>,
Matthew Wilcox <willy@infradead.org>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] buffer: fix NULL dereference of bh->b_folio in __bh_submit()
Date: Fri, 04 Sep 2026 07:28:43 +0200 [thread overview]
Message-ID: <20260904072843.tested-by-bh-submit@ferrisoft.com> (raw)
In-Reply-To: <20260902013357.2815214-1-joseph.qi@linux.alibaba.com>
On Wed, 2 Sep 2026 09:33:57 +0800, Joseph Qi wrote:
> Since commit 8deae2284976 ("buffer: allow a buffer_head to point at
> memory outside the page cache"), bh->b_folio may be NULL.
We hit the same NULL dereference independently on real hardware, and
it is nastier than a fuzzer-only finding: on an ext4 root filesystem
every boot of next-20260831 (and every later tag up to next-20260903)
dies about two minutes in. jbd2's shadow buffers have no b_folio by
design, so the first journal commit after mount oopses in
__bh_submit(), kjournald2 is killed by make_task_dead() and every
subsequent metadata write blocks forever - journald, the flush workers
and eventually all of userspace wedge in uninterruptible sleep with no
block-layer errors reported. After an unclean shutdown the crash moves
into early boot (journal recovery commits immediately), which makes
the machine effectively unbootable until a different kernel is chosen.
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
CPU: 0 UID: 0 PID: 357 Comm: jbd2/nvme0n1p18 Tainted: G W 7.3.0-rc1-next-20260831
pc : __bh_submit+0xa8/0x210
Call trace:
__bh_submit+0xa8/0x210 (P)
bh_submit+0x24/0x38
jbd2_journal_commit_transaction+0xb80/0x1ce8
kjournald2+0xb8/0x238
With this exact change applied on top of next-20260831 the same
machine (ASUS Zenbook A16 UX3607OA, Snapdragon X2 Elite, arm64) boots
reliably and has been running normally for 11+ hours.
Tested-by: Greg Ociepka <greg@ferrisoft.com>
prev parent reply other threads:[~2026-09-04 5:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 1:33 Joseph Qi
2026-09-02 20:52 ` Yalagada Pavan Kumar
2026-09-03 1:42 ` Joseph Qi
2026-09-04 10:35 ` Christian Brauner
2026-09-04 5:28 ` Greg Ociepka [this message]
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=20260904072843.tested-by-bh-submit@ferrisoft.com \
--to=greg@ferrisoft.com \
--cc=brauner@kernel.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavankumaryalagada@gmail.com \
--cc=willy@infradead.org \
/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®