mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>


      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®