Linux EXT4 FS development
 help / color / mirror / Atom feed
From: Junzhe Yu <junzheyu1@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>, Andreas Dilger <adilger.kernel@dilger.ca>
Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] ext4: guard against NULL s_group_info in ext4_get_group_info
Date: Tue, 4 Aug 2026 12:55:33 +0800	[thread overview]
Message-ID: <65c955b0-716b-4599-b925-59c2782e38b4@gmail.com> (raw)

Resend: previous attempt was rejected by vger for containing HTML.

==================================================================

ext4_mark_group_bitmap_corrupted() already treats a NULL return from
ext4_get_group_info() as "nothing to do", but ext4_get_group_info()
indexes s_group_info without checking whether the array exists.

During mount, fast-commit replay runs inside jbd2_journal_load() from
ext4_load_and_init_journal(), which is before ext4_mb_init() allocates
s_group_info. Replaying an FC UNLINK for an inode whose bitmap bit is
already clear takes:

   ext4_fc_replay_unlink -> iput -> ext4_evict_inode -> ext4_free_inode
     -> ext4_mark_group_bitmap_corrupted -> ext4_get_group_info

and faults on the NULL s_group_info base. Userspace only mounts a dirty
ext4 image; this is a supported recovery path.

Return NULL when s_group_info (or the per-block grp_info row) is unset
so the existing caller check is effective during early mount.

Tested on Linux v6.6.145 KASAN: crafted FC-unlink image previously
triggered KASAN null-ptr-deref / panic in ext4_get_group_info; with this
patch, mount succeeds (EXT4 "bit already cleared" may still log). Also
observed on v6.6.144; still present on torvalds/linux as of
f5098b6bae76 (2026-07-26).

A self-contained Docker/QEMU reproducer (craft + mount + patch verify) is
available on request.

Signed-off-by: Yu Junzhe <junzheyu1@gmail.com>
---
  fs/ext4/balloc.c | 4 ++++
  1 file changed, 4 insertions(+)

diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
index 3a2dfc5..80c81bc 100644
--- a/fs/ext4/balloc.c
+++ b/fs/ext4/balloc.c
@@ -329,9 +329,13 @@ struct ext4_group_info *ext4_get_group_info(struct 
super_block *sb,

      if (unlikely(group >= EXT4_SB(sb)->s_groups_count))
          return NULL;
+    if (unlikely(!EXT4_SB(sb)->s_group_info))
+        return NULL;
      indexv = group >> (EXT4_DESC_PER_BLOCK_BITS(sb));
      indexh = group & ((EXT4_DESC_PER_BLOCK(sb)) - 1);
      grp_info = sbi_array_rcu_deref(EXT4_SB(sb), s_group_info, indexv);
+    if (unlikely(!grp_info))
+        return NULL;
      return grp_info[indexh];
  }

-- 
2.53.0



             reply	other threads:[~2026-08-04  4:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04  4:55 Junzhe Yu [this message]
2026-08-06 14:35 ` [PATCH] ext4: guard against NULL s_group_info in ext4_get_group_info Theodore Tso
2026-08-06 15:00 ` Theodore Ts'o

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=65c955b0-716b-4599-b925-59c2782e38b4@gmail.com \
    --to=junzheyu1@gmail.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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