From: Edward Adam Davis <eadavis@qq.com>
To: syzbot+b4a2af3000eaa84d95d5@syzkaller.appspotmail.com
Cc: clm@fb.com, dsterba@suse.com, josef@toxicpanda.com,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
syzkaller-bugs@googlegroups.com
Subject: [PATCH] btrfs: Sync read disk supper and set block size
Date: Fri, 9 Jan 2026 19:37:17 +0800 [thread overview]
Message-ID: <tencent_7744F7621777A6DDB366E374C97F83BEE405@qq.com> (raw)
In-Reply-To: <695faa63.050a0220.1c677c.039b.GAE@google.com>
When the user performs a btrfs mount, the block device is not set
correctly. The user sets the block size of the block device to 0x4000
by executing the BLKBSZSET command.
Since the block size change also changes the mapping->flags value, this
further affects the result of the mapping_min_folio_order() calculation.
Let's analyze the following two scenarios:
Scenario 1: Without executing the BLKBSZSET command, the block size is
0x1000, and mapping_min_folio_order() returns 0;
Scenario 2: After executing the BLKBSZSET command, the block size is
0x4000, and mapping_min_folio_order() returns 2.
do_read_cache_folio() allocates a folio before the BLKBSZSET command
is executed. This results in the allocated folio having an order value
of 0. Later, after BLKBSZSET is executed, the block size increases to
0x4000, and the mapping_min_folio_order() calculation result becomes 2.
This leads to two undesirable consequences:
1. filemap_add_folio() triggers a VM_BUG_ON_FOLIO(folio_order(folio) <
mapping_min_folio_order(mapping)) assertion.
2. The syzbot report [1] shows a null pointer dereference in
create_empty_buffers() due to a buffer head allocation failure.
Synchronization should be established based on the inode between the
BLKBSZSET command and read cache page to prevent inconsistencies in
block size or mapping flags before and after folio allocation.
[1]
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:create_empty_buffers+0x4d/0x480 fs/buffer.c:1694
Call Trace:
folio_create_buffers+0x109/0x150 fs/buffer.c:1802
block_read_full_folio+0x14c/0x850 fs/buffer.c:2403
filemap_read_folio+0xc8/0x2a0 mm/filemap.c:2496
do_read_cache_folio+0x266/0x5c0 mm/filemap.c:4096
do_read_cache_page mm/filemap.c:4162 [inline]
read_cache_page_gfp+0x29/0x120 mm/filemap.c:4195
btrfs_read_disk_super+0x192/0x500 fs/btrfs/volumes.c:1367
Reported-by: syzbot+b4a2af3000eaa84d95d5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b4a2af3000eaa84d95d5
Tested-by: syzbot+b4a2af3000eaa84d95d5@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
fs/btrfs/volumes.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 13c514684cfb..eee7471a3e03 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1339,6 +1339,7 @@ struct btrfs_super_block *btrfs_read_disk_super(struct block_device *bdev,
struct page *page;
u64 bytenr, bytenr_orig;
struct address_space *mapping = bdev->bd_mapping;
+ struct inode *inode = mapping->host;
int ret;
bytenr_orig = btrfs_sb_offset(copy_num);
@@ -1364,7 +1365,9 @@ struct btrfs_super_block *btrfs_read_disk_super(struct block_device *bdev,
(bytenr + BTRFS_SUPER_INFO_SIZE) >> PAGE_SHIFT);
}
+ inode_lock(inode);
page = read_cache_page_gfp(mapping, bytenr >> PAGE_SHIFT, GFP_NOFS);
+ inode_unlock(inode);
if (IS_ERR(page))
return ERR_CAST(page);
--
2.43.0
next prev parent reply other threads:[~2026-01-09 11:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-08 13:00 [syzbot] [btrfs?] general protection fault in create_empty_buffers (5) syzbot
2026-01-09 4:30 ` Edward Adam Davis
2026-01-09 4:50 ` syzbot
2026-01-09 5:44 ` Forwarded: [PATCH] btrfs: validate block device block size before reading superblock syzbot
2026-01-09 8:06 ` Forwarded: [PATCH] btrfs: debug folio_alloc_buffers parameters syzbot
2026-01-09 8:43 ` Forwarded: [PATCH] btrfs: reject devices with block size larger than PAGE_SIZE syzbot
2026-01-09 9:09 ` Forwarded: [PATCH] btrfs: debug block device parameters before reading superblock syzbot
2026-01-09 10:49 ` [syzbot] [btrfs?] general protection fault in create_empty_buffers (5) Edward Adam Davis
2026-01-09 11:04 ` syzbot
2026-01-09 11:14 ` Edward Adam Davis
2026-01-09 11:36 ` syzbot
2026-01-09 11:37 ` Edward Adam Davis [this message]
2026-01-09 12:43 ` [PATCH] btrfs: Sync read disk supper and set block size Filipe Manana
2026-01-09 13:02 ` [PATCH v2] btrfs: Sync read disk super " Edward Adam Davis
2026-01-09 17:21 ` Filipe Manana
2026-01-09 21:04 ` Qu Wenruo
2026-01-09 12:56 ` [PATCH] " Edward Adam Davis
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=tencent_7744F7621777A6DDB366E374C97F83BEE405@qq.com \
--to=eadavis@qq.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+b4a2af3000eaa84d95d5@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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
Powered by JetHome