From: Elliot Berman <elliotjb@elliotjb.com>
To: Theodore Ts'o <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Sasha Levin <sashal@kernel.org>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Konstantin Komarov <almaz.alexandrovich@paragon-software.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Yongjian Sun <sunyongjian1@huawei.com>, Jan Kara <jack@suse.cz>
Cc: stable@vger.kernel.org, regressions@lists.linux.dev,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
ntfs3@lists.linux.dev, Tom Bereknyei <tomberek@gmail.com>,
Elliot Berman <elliotjb@elliotjb.com>
Subject: [PATCH 6.1.y 1/2] ext4: fix NULL folio dereference in mballoc
Date: Mon, 02 Nov 2026 06:37:03 -0800 [thread overview]
Message-ID: <20261102-ext4-ntfs3-null-folio-v1-1-4fd91ee23a4a@elliotjb.com> (raw)
In-Reply-To: <20261102-ext4-ntfs3-null-folio-v1-0-4fd91ee23a4a@elliotjb.com>
In 6.1, __filemap_get_folio() returns NULL on failure. The backported
folio conversion of mballoc keeps the original IS_ERR() checks, so they
are always false here. The fast-path lookup in ext4_mb_load_buddy_gfp()
has no FGP_CREAT and returns NULL whenever the bitmap or buddy page of
an initialised group has been evicted from the page cache, e.g. by
drop_caches or memory pressure. The next block allocation from that
group then oopses under ext4_mb_regular_allocator().
$ echo 3 > /proc/sys/vm/drop_caches, in 0.51 seconds)
$ dd if=/dev/zero of=/mnt/b0 bs=1M count=4 conv=fsync
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 5f19067 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 908 Comm: dd Not tainted 6.1.191 #1-NixOS
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
RIP: 0010:ext4_mb_load_buddy_gfp (fs/ext4/mballoc.c:1536 (discriminator 1)) ext4
Call Trace:
<TASK>
ext4_mb_regular_allocator (fs/ext4/mballoc.c:1641 fs/ext4/mballoc.c:2798) ext4
ext4_mb_new_blocks (fs/ext4/mballoc.c:5793) ext4
? ext4_find_extent (fs/ext4/extents.c:925) ext4
ext4_ext_map_blocks (fs/ext4/extents.c:4369) ext4
...
Check for NULL instead and return -ENOMEM, as failures did before the
conversion.
Fixes: d34e4fd4e73f ("ext4: convert bd_bitmap_page to bd_bitmap_folio")
Fixes: 862483175d3d ("ext4: convert bd_buddy_page to bd_buddy_folio")
Reported-by: Tom Bereknyei <tomberek@gmail.com>
Signed-off-by: Elliot Berman <elliotjb@elliotjb.com>
---
fs/ext4/mballoc.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index e77d56c533c0..d0b276ce9401 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -1375,8 +1375,8 @@ static int ext4_mb_get_buddy_page_lock(struct super_block *sb,
poff = block % blocks_per_page;
folio = __filemap_get_folio(inode->i_mapping, pnum,
FGP_LOCK | FGP_ACCESSED | FGP_CREAT, gfp);
- if (IS_ERR(folio))
- return PTR_ERR(folio);
+ if (!folio)
+ return -ENOMEM;
BUG_ON(folio->mapping != inode->i_mapping);
e4b->bd_bitmap_folio = folio;
e4b->bd_bitmap = folio_address(folio) + (poff * sb->s_blocksize);
@@ -1389,8 +1389,8 @@ static int ext4_mb_get_buddy_page_lock(struct super_block *sb,
/* blocks_per_page == 1, hence we need another page for the buddy */
folio = __filemap_get_folio(inode->i_mapping, block + 1,
FGP_LOCK | FGP_ACCESSED | FGP_CREAT, gfp);
- if (IS_ERR(folio))
- return PTR_ERR(folio);
+ if (!folio)
+ return -ENOMEM;
BUG_ON(folio->mapping != inode->i_mapping);
e4b->bd_buddy_folio = folio;
return 0;
@@ -1533,7 +1533,7 @@ ext4_mb_load_buddy_gfp(struct super_block *sb, ext4_group_t group,
/* Avoid locking the folio in the fast path ... */
folio = __filemap_get_folio(inode->i_mapping, pnum, FGP_ACCESSED, 0);
- if (IS_ERR(folio) || !folio_test_uptodate(folio) || folio_test_locked(folio)) {
+ if (!folio || !folio_test_uptodate(folio) || folio_test_locked(folio)) {
/*
* folio_test_locked is employed to detect ongoing folio
* migrations, since concurrent migrations can lead to
@@ -1543,11 +1543,11 @@ ext4_mb_load_buddy_gfp(struct super_block *sb, ext4_group_t group,
* try to get the folio with lock in both cases to avoid
* concurrency.
*/
- if (!IS_ERR(folio))
+ if (folio)
folio_put(folio);
folio = __filemap_get_folio(inode->i_mapping, pnum,
FGP_LOCK | FGP_ACCESSED | FGP_CREAT, gfp);
- if (!IS_ERR(folio)) {
+ if (folio) {
if (WARN_RATELIMIT(folio->mapping != inode->i_mapping,
"ext4: bitmap's mapping != inode->i_mapping\n")) {
/* should never happen */
@@ -1567,8 +1567,8 @@ ext4_mb_load_buddy_gfp(struct super_block *sb, ext4_group_t group,
folio_unlock(folio);
}
}
- if (IS_ERR(folio)) {
- ret = PTR_ERR(folio);
+ if (!folio) {
+ ret = -ENOMEM;
goto err;
}
if (!folio_test_uptodate(folio)) {
@@ -1585,12 +1585,12 @@ ext4_mb_load_buddy_gfp(struct super_block *sb, ext4_group_t group,
poff = block % blocks_per_page;
folio = __filemap_get_folio(inode->i_mapping, pnum, FGP_ACCESSED, 0);
- if (IS_ERR(folio) || !folio_test_uptodate(folio) || folio_test_locked(folio)) {
- if (!IS_ERR(folio))
+ if (!folio || !folio_test_uptodate(folio) || folio_test_locked(folio)) {
+ if (folio)
folio_put(folio);
folio = __filemap_get_folio(inode->i_mapping, pnum,
FGP_LOCK | FGP_ACCESSED | FGP_CREAT, gfp);
- if (!IS_ERR(folio)) {
+ if (folio) {
if (WARN_RATELIMIT(folio->mapping != inode->i_mapping,
"ext4: buddy bitmap's mapping != inode->i_mapping\n")) {
/* should never happen */
@@ -1609,8 +1609,8 @@ ext4_mb_load_buddy_gfp(struct super_block *sb, ext4_group_t group,
folio_unlock(folio);
}
}
- if (IS_ERR(folio)) {
- ret = PTR_ERR(folio);
+ if (!folio) {
+ ret = -ENOMEM;
goto err;
}
if (!folio_test_uptodate(folio)) {
--
2.54.0
next prev parent reply other threads:[~2026-11-02 14:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 14:37 [PATCH 6.1.y 0/2] Fix NULL folio dereferences from IS_ERR() checks in 6.1.191 Elliot Berman
2026-11-02 14:37 ` Elliot Berman [this message]
2026-11-02 14:37 ` [PATCH 6.1.y 2/2] bs/ntfs3: fix NULL folio dereference in ntfs_lock_new_page() Elliot Berman
2026-11-02 17:22 ` [PATCH 6.1.y 0/2] Fix NULL folio dereferences from IS_ERR() checks in 6.1.191 Naman Jain
2026-11-03 1:42 ` Kevin Fernandez
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=20261102-ext4-ntfs3-null-folio-v1-1-4fd91ee23a4a@elliotjb.com \
--to=elliotjb@elliotjb.com \
--cc=adilger.kernel@dilger.ca \
--cc=almaz.alexandrovich@paragon-software.com \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ntfs3@lists.linux.dev \
--cc=regressions@lists.linux.dev \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=sunyongjian1@huawei.com \
--cc=tomberek@gmail.com \
--cc=tytso@mit.edu \
--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®