[syzbot] [btrfs?] general protection fault in create_empty_buffers (5)

[syzbot] [btrfs?] general protection fault in create_empty_buffers (5)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    f0b9d8eb98df Merge tag 'nfsd-6.19-3' of git://git.kernel.o..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1311ef92580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=a11e0f726bfb6765
dashboard link: https://syzkaller.appspot.com/bug?extid=b4a2af3000eaa84d95d5
compiler:       gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10663e9a580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14936074580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-f0b9d8eb.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/d6eefae97e89/vmlinux-f0b9d8eb.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a16fafcc4238/bzImage-f0b9d8eb.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+b4a2af3000eaa84d95d5@syzkaller.appspotmail.com

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 2 UID: 0 PID: 6261 Comm: syz.0.73 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:create_empty_buffers+0x4d/0x480 fs/buffer.c:1694
Code: ec 6d ff 48 89 de ba 40 8c 40 00 4c 89 ef e8 0a f6 ff ff 49 89 c6 48 89 c3 eb 03 48 89 c3 e8 ea eb 6d ff 48 89 d8 48 c1 e8 03 <80> 3c 28 00 0f 85 81 03 00 00 48 8d 7b 08 4c 09 23 48 89 f8 48 c1
RSP: 0018:ffffc9000408f870 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8250f7ec
RDX: ffff88802a4d8000 RSI: ffffffff8250fcc6 RDI: ffff88802a4d9680
RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: ffff88802a4d8b30 R12: 0000000000000000
R13: ffffea0000a9e5c0 R14: 0000000000000000 R15: dffffc0000000000
FS:  00007f1ac84a46c0(0000) GS:ffff8880d6af5000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1ac84a3f98 CR3: 000000002b14f000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 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
 btrfs_scan_one_device+0x109/0x820 fs/btrfs/volumes.c:1475
 btrfs_get_tree_super fs/btrfs/super.c:1860 [inline]
 btrfs_get_tree_subvol fs/btrfs/super.c:2089 [inline]
 btrfs_get_tree+0x5b3/0x2710 fs/btrfs/super.c:2123
 vfs_get_tree+0x8e/0x330 fs/super.c:1751
 fc_mount fs/namespace.c:1199 [inline]
 do_new_mount_fc fs/namespace.c:3636 [inline]
 do_new_mount fs/namespace.c:3712 [inline]
 path_mount+0x7bf/0x23a0 fs/namespace.c:4022
 do_mount fs/namespace.c:4035 [inline]
 __do_sys_mount fs/namespace.c:4224 [inline]
 __se_sys_mount fs/namespace.c:4201 [inline]
 __x64_sys_mount+0x293/0x310 fs/namespace.c:4201
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f1ac758f7c9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f1ac84a4038 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f1ac77e6090 RCX: 00007f1ac758f7c9
RDX: 00002000000000c0 RSI: 0000200000000080 RDI: 00002000000001c0
RBP: 00007f1ac7613f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000004418 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f1ac77e6128 R14: 00007f1ac77e6090 R15: 00007ffe5d1bb9d8
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:create_empty_buffers+0x4d/0x480 fs/buffer.c:1694
Code: ec 6d ff 48 89 de ba 40 8c 40 00 4c 89 ef e8 0a f6 ff ff 49 89 c6 48 89 c3 eb 03 48 89 c3 e8 ea eb 6d ff 48 89 d8 48 c1 e8 03 <80> 3c 28 00 0f 85 81 03 00 00 48 8d 7b 08 4c 09 23 48 89 f8 48 c1
RSP: 0018:ffffc9000408f870 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8250f7ec
RDX: ffff88802a4d8000 RSI: ffffffff8250fcc6 RDI: ffff88802a4d9680
RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: ffff88802a4d8b30 R12: 0000000000000000
R13: ffffea0000a9e5c0 R14: 0000000000000000 R15: dffffc0000000000
FS:  00007f1ac84a46c0(0000) GS:ffff8880d6af5000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1ac84a3f98 CR3: 000000002b14f000 CR4: 0000000000352ef0
----------------
Code disassembly (best guess):
   0:	ec                   	in     (%dx),%al
   1:	6d                   	insl   (%dx),%es:(%rdi)
   2:	ff 48 89             	decl   -0x77(%rax)
   5:	de ba 40 8c 40 00    	fidivrs 0x408c40(%rdx)
   b:	4c 89 ef             	mov    %r13,%rdi
   e:	e8 0a f6 ff ff       	call   0xfffff61d
  13:	49 89 c6             	mov    %rax,%r14
  16:	48 89 c3             	mov    %rax,%rbx
  19:	eb 03                	jmp    0x1e
  1b:	48 89 c3             	mov    %rax,%rbx
  1e:	e8 ea eb 6d ff       	call   0xff6dec0d
  23:	48 89 d8             	mov    %rbx,%rax
  26:	48 c1 e8 03          	shr    $0x3,%rax
* 2a:	80 3c 28 00          	cmpb   $0x0,(%rax,%rbp,1) <-- trapping instruction
  2e:	0f 85 81 03 00 00    	jne    0x3b5
  34:	48 8d 7b 08          	lea    0x8(%rbx),%rdi
  38:	4c 09 23             	or     %r12,(%rbx)
  3b:	48 89 f8             	mov    %rdi,%rax
  3e:	48                   	rex.W
  3f:	c1                   	.byte 0xc1


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [btrfs?] general protection fault in create_empty_buffers (5)

[Edward Adam Davis]

#syz test

diff --git a/block/fops.c b/block/fops.c
index 4d32785b31d9..c0cdc950d94c 100644
--- a/block/fops.c
+++ b/block/fops.c
@@ -492,6 +492,9 @@ static int blkdev_writepages(struct address_space *mapping,
 
 static int blkdev_read_folio(struct file *file, struct folio *folio)
 {
+	if (1 << READ_ONCE(folio->mapping->host->i_blkbits) > folio_size(folio))
+		return -EIO;
+
 	return block_read_full_folio(folio, blkdev_get_block);
 }
 

Re: [syzbot] [btrfs?] general protection fault in create_empty_buffers (5)

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
kernel BUG in __filemap_add_folio

 process_scheduled_works kernel/workqueue.c:3340 [inline]
 worker_thread+0x6c8/0xf10 kernel/workqueue.c:3421
 kthread+0x3c5/0x780 kernel/kthread.c:463
 ret_from_fork+0x983/0xb10 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
------------[ cut here ]------------
kernel BUG at mm/filemap.c:858!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 2 UID: 0 PID: 8695 Comm: syz.0.781 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:__filemap_add_folio+0xf29/0x11b0 mm/filemap.c:858
Code: 96 c6 ff 48 c7 c6 80 ed 99 8b 4c 89 ef e8 bf 72 11 00 90 0f 0b e8 77 96 c6 ff 48 c7 c6 e0 ed 99 8b 4c 89 ef e8 a8 72 11 00 90 <0f> 0b e8 60 96 c6 ff 90 0f 0b 90 e9 1c fc ff ff e8 52 96 c6 ff 48
RSP: 0018:ffffc9000c72f808 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff888026b024c0 RSI: ffffffff81f85248 RDI: ffff888026b02944
RBP: 0000000000000c40 R08: 0000000000000001 R09: 0000000000000001
R10: ffffffff9088bbd7 R11: 0000000000000001 R12: 0000000000000002
R13: ffffea0000ce5bc0 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f7a297d56c0(0000) GS:ffff8880d6af5000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7a297d4f98 CR3: 0000000035522000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 filemap_add_folio+0x19a/0x610 mm/filemap.c:966
 do_read_cache_folio+0x23c/0x5c0 mm/filemap.c:4063
 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
 btrfs_scan_one_device+0x109/0x820 fs/btrfs/volumes.c:1475
 btrfs_get_tree_super fs/btrfs/super.c:1860 [inline]
 btrfs_get_tree_subvol fs/btrfs/super.c:2089 [inline]
 btrfs_get_tree+0x5b3/0x2710 fs/btrfs/super.c:2123
 vfs_get_tree+0x8e/0x330 fs/super.c:1751
 fc_mount fs/namespace.c:1199 [inline]
 do_new_mount_fc fs/namespace.c:3636 [inline]
 do_new_mount fs/namespace.c:3712 [inline]
 path_mount+0x7bf/0x23a0 fs/namespace.c:4022
 do_mount fs/namespace.c:4035 [inline]
 __do_sys_mount fs/namespace.c:4224 [inline]
 __se_sys_mount fs/namespace.c:4201 [inline]
 __x64_sys_mount+0x293/0x310 fs/namespace.c:4201
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f7a2898f7c9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f7a297d5038 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f7a28be6090 RCX: 00007f7a2898f7c9
RDX: 00002000000000c0 RSI: 0000200000000080 RDI: 00002000000001c0
RBP: 00007f7a28a13f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000004418 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f7a28be6128 R14: 00007f7a28be6090 R15: 00007fff39c82018
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__filemap_add_folio+0xf29/0x11b0 mm/filemap.c:858
Code: 96 c6 ff 48 c7 c6 80 ed 99 8b 4c 89 ef e8 bf 72 11 00 90 0f 0b e8 77 96 c6 ff 48 c7 c6 e0 ed 99 8b 4c 89 ef e8 a8 72 11 00 90 <0f> 0b e8 60 96 c6 ff 90 0f 0b 90 e9 1c fc ff ff e8 52 96 c6 ff 48
RSP: 0018:ffffc9000c72f808 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff888026b024c0 RSI: ffffffff81f85248 RDI: ffff888026b02944
RBP: 0000000000000c40 R08: 0000000000000001 R09: 0000000000000001
R10: ffffffff9088bbd7 R11: 0000000000000001 R12: 0000000000000002
R13: ffffea0000ce5bc0 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f7a297d56c0(0000) GS:ffff8880d6af5000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7a297d4f98 CR3: 0000000035522000 CR4: 0000000000352ef0


Tested on:

commit:         623fb991 Merge tag 'pinctrl-v6.19-2' of git://git.kern..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1689319a580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=a11e0f726bfb6765
dashboard link: https://syzkaller.appspot.com/bug?extid=b4a2af3000eaa84d95d5
compiler:       gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=14bd9074580000

Forwarded: [PATCH] btrfs: validate block device block size before reading superblock

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] btrfs: validate block device block size before reading superblock
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

When mounting a block device with a block size larger than PAGE_SIZE,
the buffer head allocation in folio_alloc_buffers() returns NULL because
the allocation loop never executes when blocksize > folio_size. This
leads to a NULL pointer dereference in create_empty_buffers() when
accessing bh->b_state.

The crash was triggered by syzbot mounting a null_blk device as btrfs,
where the block device had a block size exceeding PAGE_SIZE.

Add validation in btrfs_read_disk_super() to reject block devices with
block sizes larger than PAGE_SIZE before attempting to read the
superblock.

Reported-by: syzbot+b4a2af3000eaa84d95d5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b4a2af3000eaa84d95d5
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.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..d79e2a19c046 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1341,6 +1341,9 @@ struct btrfs_super_block *btrfs_read_disk_super(struct block_device *bdev,
 	struct address_space *mapping = bdev->bd_mapping;
 	int ret;
 
+	if (!mapping->host ||
+	    (1 << mapping->host->i_blkbits) > PAGE_SIZE)
+		return ERR_PTR(-EINVAL);
 	bytenr_orig = btrfs_sb_offset(copy_num);
 	ret = btrfs_sb_log_location_bdev(bdev, copy_num, READ, &bytenr);
 	if (ret < 0) {
-- 
2.43.0

Forwarded: [PATCH] btrfs: debug folio_alloc_buffers parameters

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] btrfs: debug folio_alloc_buffers parameters
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

Debug patch to understand NULL pointer dereference in create_empty_buffers.
Print folio_size and blocksize to identify why folio_alloc_buffers returns NULL.

NOT FOR MERGE - debug only.

Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/buffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index 838c0c571022..487a32faaa16 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -928,7 +928,7 @@ struct buffer_head *folio_alloc_buffers(struct folio *folio, unsigned long size,
 	/* The folio lock pins the memcg */
 	memcg = folio_memcg(folio);
 	old_memcg = set_active_memcg(memcg);
-
+	pr_err("DEBUG: folio_size=%lu blocksize=%lu\n",folio_size(folio), size);
 	head = NULL;
 	offset = folio_size(folio);
 	while ((offset -= size) >= 0) {
-- 
2.43.0

Forwarded: [PATCH] btrfs: reject devices with block size larger than PAGE_SIZE

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] btrfs: reject devices with block size larger than PAGE_SIZE
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

When a block device has a block size larger than PAGE_SIZE, the page
cache allocates folios that are too small for the device's requirements.
This causes folio_alloc_buffers() to return NULL (loop never executes
when blocksize > folio_size), leading to a NULL pointer dereference in
create_empty_buffers() when accessing bh->b_state.

The bug was triggered by mounting a null_blk device configured with
large block size as btrfs. The crash path is:

  btrfs_read_disk_super()
    read_cache_page_gfp()        <- allocates 4KB folio
      do_read_cache_folio()
        block_read_full_folio()
          folio_create_buffers()
            create_empty_buffers()
              folio_alloc_buffers()  <- returns NULL (16KB > 4KB)
              bh->b_state            <- NULL deref crash

Add a check to reject block devices with block size larger than
PAGE_SIZE before attempting to read the superblock.

Reported-by: syzbot+b4a2af3000eaa84d95d5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b4a2af3000eaa84d95d5
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/btrfs/volumes.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 13c514684cfb..1d529e408f5c 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1341,6 +1341,10 @@ struct btrfs_super_block *btrfs_read_disk_super(struct block_device *bdev,
 	struct address_space *mapping = bdev->bd_mapping;
 	int ret;
 
+	/* Reject devices with block size larger than PAGE_SIZE */
+	if (bdev_logical_block_size(bdev) > PAGE_SIZE)
+		return ERR_PTR(-EINVAL);
+
 	bytenr_orig = btrfs_sb_offset(copy_num);
 	ret = btrfs_sb_log_location_bdev(bdev, copy_num, READ, &bytenr);
 	if (ret < 0) {
-- 
2.43.0

Forwarded: [PATCH] btrfs: debug block device parameters before reading superblock

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] btrfs: debug block device parameters before reading superblock
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

Debug patch to understand NULL pointer dereference in create_empty_buffers.
Print logical_block_size and mapping_min_folio_order to identify the correct
check needed.

NOT FOR MERGE - debug only.

Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.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..40de5be63172 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1341,6 +1341,9 @@ struct btrfs_super_block *btrfs_read_disk_super(struct block_device *bdev,
 	struct address_space *mapping = bdev->bd_mapping;
 	int ret;
 
+	pr_err("DEBUG btrfs: logical_block_size=%u min_folio_order=%u\n",
+		 bdev_logical_block_size(bdev),
+		mapping_min_folio_order(mapping));
 	bytenr_orig = btrfs_sb_offset(copy_num);
 	ret = btrfs_sb_log_location_bdev(bdev, copy_num, READ, &bytenr);
 	if (ret < 0) {
-- 
2.43.0

Re: [syzbot] [btrfs?] general protection fault in create_empty_buffers (5)

[Edward Adam Davis]

#syz test

diff --git a/mm/filemap.c b/mm/filemap.c
index ebd75684cb0a..9044a4087ce5 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -4048,17 +4048,22 @@ EXPORT_SYMBOL(generic_file_readonly_mmap_prepare);
 static struct folio *do_read_cache_folio(struct address_space *mapping,
 		pgoff_t index, filler_t filler, struct file *file, gfp_t gfp)
 {
+	struct inode *inode = mapping->host;
 	struct folio *folio;
 	int err;
 
 	if (!filler)
 		filler = mapping->a_ops->read_folio;
+	inode_lock(inode);
 repeat:
 	folio = filemap_get_folio(mapping, index);
 	if (IS_ERR(folio)) {
 		folio = filemap_alloc_folio(gfp, mapping_min_folio_order(mapping), NULL);
-		if (!folio)
+		if (!folio) {
+			inode_unlock(inode);
 			return ERR_PTR(-ENOMEM);
+		}
+
 		index = mapping_align_index(mapping, index);
 		err = filemap_add_folio(mapping, folio, index, gfp);
 		if (unlikely(err)) {
@@ -4066,13 +4071,16 @@ static struct folio *do_read_cache_folio(struct address_space *mapping,
 			if (err == -EEXIST)
 				goto repeat;
 			/* Presumably ENOMEM for xarray node */
+			inode_unlock(inode);
 			return ERR_PTR(err);
 		}
 
 		goto filler;
 	}
-	if (folio_test_uptodate(folio))
+	if (folio_test_uptodate(folio)) {
+		inode_unlock(inode);
 		goto out;
+	}
 
 	if (!folio_trylock(folio)) {
 		folio_put_wait_locked(folio, TASK_UNINTERRUPTIBLE);
@@ -4089,11 +4097,13 @@ static struct folio *do_read_cache_folio(struct address_space *mapping,
 	/* Someone else locked and filled the page in a very small window */
 	if (folio_test_uptodate(folio)) {
 		folio_unlock(folio);
+		inode_unlock(inode);
 		goto out;
 	}
 
 filler:
 	err = filemap_read_folio(file, filler, folio);
+	inode_unlock(inode);
 	if (err) {
 		folio_put(folio);
 		if (err == AOP_TRUNCATED_PAGE)

Re: [syzbot] [btrfs?] general protection fault in create_empty_buffers (5)

[syzbot]

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

possible deadlock in do_read_cache_folio

============================================
WARNING: possible recursive locking detected
syzkaller #0 Not tainted
--------------------------------------------
syz-executor/5943 is trying to acquire lock:
ffff88803d88bda0 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: inode_lock include/linux/fs.h:1027 [inline]
ffff88803d88bda0 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: do_read_cache_folio+0x71/0x630 mm/filemap.c:4057

but task is already holding lock:
ffff88803d88bda0 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: inode_lock include/linux/fs.h:1027 [inline]
ffff88803d88bda0 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: __do_sys_swapon+0x8c5/0x3b30 mm/swapfile.c:3447

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&sb->s_type->i_mutex_key#9);
  lock(&sb->s_type->i_mutex_key#9);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

1 lock held by syz-executor/5943:
 #0: ffff88803d88bda0 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: inode_lock include/linux/fs.h:1027 [inline]
 #0: ffff88803d88bda0 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: __do_sys_swapon+0x8c5/0x3b30 mm/swapfile.c:3447

stack backtrace:
CPU: 2 UID: 0 PID: 5943 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
 print_deadlock_bug+0x225/0x2f0 kernel/locking/lockdep.c:3041
 check_deadlock kernel/locking/lockdep.c:3093 [inline]
 validate_chain kernel/locking/lockdep.c:3895 [inline]
 __lock_acquire+0x1497/0x2890 kernel/locking/lockdep.c:5237
 lock_acquire kernel/locking/lockdep.c:5868 [inline]
 lock_acquire+0x179/0x330 kernel/locking/lockdep.c:5825
 down_write+0x92/0x200 kernel/locking/rwsem.c:1590
 inode_lock include/linux/fs.h:1027 [inline]
 do_read_cache_folio+0x71/0x630 mm/filemap.c:4057
 read_mapping_folio include/linux/pagemap.h:1017 [inline]
 __do_sys_swapon+0xa3c/0x3b30 mm/swapfile.c:3473
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f6eec78f687
Code: 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 a7 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffdb225a028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a7
RAX: ffffffffffffffda RBX: 00007ffdb225a030 RCX: 00007f6eec78f687
RDX: 0000000000000000 RSI: 0000000000008000 RDI: 00007f6eec814bc1
RBP: 00007f6eec814bc1 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000008 R11: 0000000000000246 R12: 00007f6eec9b4270
R13: 0000000000000000 R14: 00007f6eec830975 R15: 00007f6eec8309b1
 </TASK>


[   53.084811][   T40] audit: type=1400 audit(1767956586.888:60): avc:  denied  { rlimitinh } for  pid=5908 comm="sh" scontext=system_u:system_r:sshd_t tcontext=root:sysadm_r:sysadm_t tclass=process permissive=1
[   53.096835][   T40] audit: type=1400 audit(1767956586.888:61): avc:  denied  { siginh } for  pid=5908 comm="sh" scontext=system_u:system_r:sshd_t tcontext=root:sysadm_r:sysadm_t tclass=process permissive=1
Warning: Permanently added '[localhost]:9988' (ED25519) to the list of known hosts.
[   60.278181][   T40] audit: type=1400 audit(1767956594.098:62): avc:  denied  { execute } for  pid=5933 comm="sh" name="syz-execprog" dev="sda1" ino=2020 scontext=root:sysadm_r:sysadm_t tcontext=root:object_r:etc_runtime_t tclass=file permissive=1
[   60.287411][   T40] audit: type=1400 audit(1767956594.098:63): avc:  denied  { execute_no_trans } for  pid=5933 comm="sh" path="/syz-execprog" dev="sda1" ino=2020 scontext=root:sysadm_r:sysadm_t tcontext=root:object_r:etc_runtime_t tclass=file permissive=1
2026/01/09 11:03:15 parsed 1 programs
[   61.777835][   T40] audit: type=1400 audit(1767956595.598:64): avc:  denied  { node_bind } for  pid=5933 comm="syz-execprog" saddr=::1 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:node_t tclass=tcp_socket permissive=1
[   64.448665][   T40] audit: type=1400 audit(1767956598.268:65): avc:  denied  { mounton } for  pid=5943 comm="syz-executor" path="/syzcgroup/unified" dev="sda1" ino=2023 scontext=root:sysadm_r:sysadm_t tcontext=root:object_r:root_t tclass=dir permissive=1
[   64.458449][   T40] audit: type=1400 audit(1767956598.278:66): avc:  denied  { mount } for  pid=5943 comm="syz-executor" name="/" dev="cgroup2" ino=1 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:cgroup_t tclass=filesystem permissive=1
[   64.460855][ T5943] cgroup: Unknown subsys name 'net'
[   64.471699][   T40] audit: type=1400 audit(1767956598.288:67): avc:  denied  { unmount } for  pid=5943 comm="syz-executor" scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:cgroup_t tclass=filesystem permissive=1
[   64.617962][ T5943] cgroup: Unknown subsys name 'cpuset'
[   64.625187][ T5943] cgroup: Unknown subsys name 'rlimit'
[   64.814304][   T40] audit: type=1400 audit(1767956598.638:68): avc:  denied  { setattr } for  pid=5943 comm="syz-executor" name="raw-gadget" dev="devtmpfs" ino=849 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:device_t tclass=chr_file permissive=1
[   64.822507][   T40] audit: type=1400 audit(1767956598.638:69): avc:  denied  { create } for  pid=5943 comm="syz-executor" scontext=root:sysadm_r:sysadm_t tcontext=root:sysadm_r:sysadm_t tclass=netlink_generic_socket permissive=1
[   64.830130][   T40] audit: type=1400 audit(1767956598.638:70): avc:  denied  { write } for  pid=5943 comm="syz-executor" scontext=root:sysadm_r:sysadm_t tcontext=root:sysadm_r:sysadm_t tclass=netlink_generic_socket permissive=1
[   64.837309][   T40] audit: type=1400 audit(1767956598.638:71): avc:  denied  { read } for  pid=5943 comm="syz-executor" scontext=root:sysadm_r:sysadm_t tcontext=root:sysadm_r:sysadm_t tclass=netlink_generic_socket permissive=1
[   64.898978][ T5946] SELinux:  Context root:object_r:swapfile_t is not valid (left unmapped).
Setting up swapspace version 1, size = 127995904 bytes
[   65.699886][ T5943] 
[   65.701037][ T5943] ============================================
[   65.703700][ T5943] WARNING: possible recursive locking detected
[   65.706218][ T5943] syzkaller #0 Not tainted
[   65.708005][ T5943] --------------------------------------------
[   65.710557][ T5943] syz-executor/5943 is trying to acquire lock:
[   65.713078][ T5943] ffff88803d88bda0 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: do_read_cache_folio+0x71/0x630
[   65.717231][ T5943] 
[   65.717231][ T5943] but task is already holding lock:
[   65.720205][ T5943] ffff88803d88bda0 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: __do_sys_swapon+0x8c5/0x3b30
[   65.724343][ T5943] 
[   65.724343][ T5943] other info that might help us debug this:
[   65.727468][ T5943]  Possible unsafe locking scenario:
[   65.727468][ T5943] 
[   65.730398][ T5943]        CPU0
[   65.731745][ T5943]        ----
[   65.733146][ T5943]   lock(&sb->s_type->i_mutex_key#9);
[   65.735015][ T5943]   lock(&sb->s_type->i_mutex_key#9);
[   65.737050][ T5943] 
[   65.737050][ T5943]  *** DEADLOCK ***
[   65.737050][ T5943] 
[   65.740266][ T5943]  May be due to missing lock nesting notation
[   65.740266][ T5943] 
[   65.743600][ T5943] 1 lock held by syz-executor/5943:
[   65.745702][ T5943]  #0: ffff88803d88bda0 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: __do_sys_swapon+0x8c5/0x3b30
[   65.749925][ T5943] 
[   65.749925][ T5943] stack backtrace:
[   65.752320][ T5943] CPU: 2 UID: 0 PID: 5943 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) 
[   65.752343][ T5943] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
[   65.752354][ T5943] Call Trace:
[   65.752363][ T5943]  <TASK>
[   65.752370][ T5943]  dump_stack_lvl+0x116/0x1f0
[   65.752397][ T5943]  print_deadlock_bug+0x225/0x2f0
[   65.752418][ T5943]  __lock_acquire+0x1497/0x2890
[   65.752442][ T5943]  lock_acquire+0x179/0x330
[   65.752461][ T5943]  ? do_read_cache_folio+0x71/0x630
[   65.752480][ T5943]  ? __pfx___might_resched+0x10/0x10
[   65.752498][ T5943]  down_write+0x92/0x200
[   65.752522][ T5943]  ? do_read_cache_folio+0x71/0x630
[   65.752539][ T5943]  ? __pfx_down_write+0x10/0x10
[   65.752564][ T5943]  ? down_write+0x14d/0x200
[   65.752587][ T5943]  do_read_cache_folio+0x71/0x630
[   65.752604][ T5943]  ? __pfx_ext4_read_folio+0x10/0x10
[   65.752622][ T5943]  __do_sys_swapon+0xa3c/0x3b30
[   65.752644][ T5943]  ? __pfx_restore_altstack+0x10/0x10
[   65.752663][ T5943]  ? lockdep_hardirqs_on+0x7c/0x110
[   65.752686][ T5943]  ? restore_signal_shadow_stack+0x63/0x460
[   65.752713][ T5943]  ? __do_sys_rt_sigreturn+0x1da/0x2c0
[   65.752739][ T5943]  ? __pfx___do_sys_swapon+0x10/0x10
[   65.752759][ T5943]  ? rcu_is_watching+0x12/0xc0
[   65.752778][ T5943]  do_syscall_64+0xcd/0xf80
[   65.752799][ T5943]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[   65.752817][ T5943] RIP: 0033:0x7f6eec78f687
[   65.752830][ T5943] Code: 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 a7 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
[   65.752847][ T5943] RSP: 002b:00007ffdb225a028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a7
[   65.752863][ T5943] RAX: ffffffffffffffda RBX: 00007ffdb225a030 RCX: 00007f6eec78f687
[   65.752875][ T5943] RDX: 0000000000000000 RSI: 0000000000008000 RDI: 00007f6eec814bc1
[   65.752885][ T5943] RBP: 00007f6eec814bc1 R08: 0000000000000000 R09: 0000000000000000
[   65.752896][ T5943] R10: 0000000000000008 R11: 0000000000000246 R12: 00007f6eec9b4270
[   65.752906][ T5943] R13: 0000000000000000 R14: 00007f6eec830975 R15: 00007f6eec8309b1
[   65.752922][ T5943]  </TASK>


syzkaller build log:
go env (err=<nil>)
AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE='auto'
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/syzkaller/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/syzkaller/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1604046123=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/syzkaller/jobs/linux/gopath/src/github.com/google/syzkaller/go.mod'
GOMODCACHE='/syzkaller/jobs/linux/gopath/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/syzkaller/jobs/linux/gopath'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/syzkaller/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.24.4'
GOWORK=''
PKG_CONFIG='pkg-config'

git status (err=<nil>)
HEAD detached at d1b870e1003
nothing to commit, working tree clean


tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
Makefile:31: run command via tools/syz-env for best compatibility, see:
Makefile:32: https://github.com/google/syzkaller/blob/master/docs/contributing.md#using-syz-env
go list -f '{{.Stale}}' -ldflags="-s -w -X github.com/google/syzkaller/prog.GitRevision=d1b870e1003b52891d2196c1e2ee42fe905010ba -X github.com/google/syzkaller/prog.gitRevisionDate=20251128-125159"  ./sys/syz-sysgen | grep -q false || go install -ldflags="-s -w -X github.com/google/syzkaller/prog.GitRevision=d1b870e1003b52891d2196c1e2ee42fe905010ba -X github.com/google/syzkaller/prog.gitRevisionDate=20251128-125159"  ./sys/syz-sysgen
make .descriptions
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
Makefile:31: run command via tools/syz-env for best compatibility, see:
Makefile:32: https://github.com/google/syzkaller/blob/master/docs/contributing.md#using-syz-env
bin/syz-sysgen
touch .descriptions
GOOS=linux GOARCH=amd64 go build -ldflags="-s -w -X github.com/google/syzkaller/prog.GitRevision=d1b870e1003b52891d2196c1e2ee42fe905010ba -X github.com/google/syzkaller/prog.gitRevisionDate=20251128-125159"  -o ./bin/linux_amd64/syz-execprog github.com/google/syzkaller/tools/syz-execprog
mkdir -p ./bin/linux_amd64
g++ -o ./bin/linux_amd64/syz-executor executor/executor.cc \
	-m64 -O2 -pthread -Wall -Werror -Wparentheses -Wunused-const-variable -Wframe-larger-than=16384 -Wno-stringop-overflow -Wno-array-bounds -Wno-format-overflow -Wno-unused-but-set-variable -Wno-unused-command-line-argument -static-pie -std=c++17 -I. -Iexecutor/_include   -DGOOS_linux=1 -DGOARCH_amd64=1 \
	-DHOSTGOOS_linux=1 -DGIT_REVISION=\"d1b870e1003b52891d2196c1e2ee42fe905010ba\"
/usr/bin/ld: /tmp/cc8lgRxb.o: in function `Connection::Connect(char const*, char const*)':
executor.cc:(.text._ZN10Connection7ConnectEPKcS1_[_ZN10Connection7ConnectEPKcS1_]+0x104): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./tools/check-syzos.sh 2>/dev/null



Tested on:

commit:         623fb991 Merge tag 'pinctrl-v6.19-2' of git://git.kern..
git tree:       upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=a11e0f726bfb6765
dashboard link: https://syzkaller.appspot.com/bug?extid=b4a2af3000eaa84d95d5
compiler:       gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=1271919a580000

Re: [syzbot] [btrfs?] general protection fault in create_empty_buffers (5)

[Edward Adam Davis]

#syz test

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);
 

Re: [syzbot] [btrfs?] general protection fault in create_empty_buffers (5)

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+b4a2af3000eaa84d95d5@syzkaller.appspotmail.com
Tested-by: syzbot+b4a2af3000eaa84d95d5@syzkaller.appspotmail.com

Tested on:

commit:         623fb991 Merge tag 'pinctrl-v6.19-2' of git://git.kern..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1667e922580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=a11e0f726bfb6765
dashboard link: https://syzkaller.appspot.com/bug?extid=b4a2af3000eaa84d95d5
compiler:       gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=11c2a19a580000

Note: testing is done by a robot and is best-effort only.

[PATCH] btrfs: Sync read disk supper and set block size

[Edward Adam Davis]

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

Re: [PATCH] btrfs: Sync read disk supper and set block size

[Filipe Manana]

On Fri, Jan 9, 2026 at 11:42 AM Edward Adam Davis <eadavis@qq.com> wrote:
>
> 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.

While that fixes the problem, I'd rather lock the invalidation lock
instead of the inode:

filemap_invalidate_lock(mapping);
page = read_cache_page_gfp(mapping, bytenr >> PAGE_SHIFT, GFP_NOFS);
filemap_invalidate_unlock(mapping);

Because that's what the documentation for read_cache_page_gfp() asks for:

/**
 (...)
 *
 * The function expects mapping->invalidate_lock to be already held.
 (...)
 */
struct page *read_cache_page_gfp(struct address_space *mapping,
pgoff_t index,
gfp_t gfp)
{
return do_read_cache_page(mapping, index, NULL, NULL, gfp);
}

That will fix the race with set_blocksize() too.

Thanks.


>
> [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
>
>

[PATCH] btrfs: Sync read disk super and set block size

[Edward Adam Davis]

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

[PATCH v2] btrfs: Sync read disk super and set block size

[Edward Adam Davis]

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
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
v1 -> v2: replace inode lock with invalidate lock

 fs/btrfs/volumes.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 13c514684cfb..68ff166fe445 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1364,7 +1364,9 @@ struct btrfs_super_block *btrfs_read_disk_super(struct block_device *bdev,
 				      (bytenr + BTRFS_SUPER_INFO_SIZE) >> PAGE_SHIFT);
 	}
 
+	filemap_invalidate_lock(mapping);
 	page = read_cache_page_gfp(mapping, bytenr >> PAGE_SHIFT, GFP_NOFS);
+	filemap_invalidate_unlock(mapping);
 	if (IS_ERR(page))
 		return ERR_CAST(page);
 
-- 
2.43.0

Re: [PATCH v2] btrfs: Sync read disk super and set block size

[Filipe Manana]

On Fri, Jan 9, 2026 at 1:02 PM Edward Adam Davis <eadavis@qq.com> wrote:
>
> 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
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>

Reviewed-by: Filipe Manana <fdmanana@suse.com>

Thanks, I've added it to the for-next branch with minor editing
(uncapitalize the first word in the subject and added some blank lines
for readability):

https://github.com/btrfs/linux/commits/for-next/

> ---
> v1 -> v2: replace inode lock with invalidate lock
>
>  fs/btrfs/volumes.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 13c514684cfb..68ff166fe445 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -1364,7 +1364,9 @@ struct btrfs_super_block *btrfs_read_disk_super(struct block_device *bdev,
>                                       (bytenr + BTRFS_SUPER_INFO_SIZE) >> PAGE_SHIFT);
>         }
>
> +       filemap_invalidate_lock(mapping);
>         page = read_cache_page_gfp(mapping, bytenr >> PAGE_SHIFT, GFP_NOFS);
> +       filemap_invalidate_unlock(mapping);
>         if (IS_ERR(page))
>                 return ERR_CAST(page);
>
> --
> 2.43.0
>

Re: [PATCH v2] btrfs: Sync read disk super and set block size

[Qu Wenruo]

在 2026/1/9 23:32, Edward Adam Davis 写道:
> When the user performs a btrfs mount, the block device is not set
> correctly.

Explain "the block device is not set correctly", all your later commit 
message is showing that it's end user re-setting the device block size.
There is nothing "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.

Although I agree with the analyze so far, I didn't see we should 
continue stick to the old read_page_cache_gfp() call.

There is already an old series which will address it pretty well:

https://lore.kernel.org/linux-btrfs/cover.1752097916.git.wqu@suse.com/

Although at that time I'm not aware of the race between blocksize set 
and read_page_cache_gfp().

Since btrfs is the last one utilizing this interface, I think it's 
better to completely remove it other than bothering the extra locking 
requirement.

> 
> 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
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>

Anyway you won't reply to any review/comment, I doubt if you will change 
this time.


> ---
> v1 -> v2: replace inode lock with invalidate lock
> 
>   fs/btrfs/volumes.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 13c514684cfb..68ff166fe445 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -1364,7 +1364,9 @@ struct btrfs_super_block *btrfs_read_disk_super(struct block_device *bdev,
>   				      (bytenr + BTRFS_SUPER_INFO_SIZE) >> PAGE_SHIFT);
>   	}
>   
> +	filemap_invalidate_lock(mapping);
>   	page = read_cache_page_gfp(mapping, bytenr >> PAGE_SHIFT, GFP_NOFS);
> +	filemap_invalidate_unlock(mapping);
>   	if (IS_ERR(page))
>   		return ERR_CAST(page);
>   

Re: [syzbot] [btrfs?] general protection fault in create_empty_buffers (5)

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+b4a2af3000eaa84d95d5@syzkaller.appspotmail.com
Tested-by: syzbot+b4a2af3000eaa84d95d5@syzkaller.appspotmail.com

Tested on:

commit:         623fb991 Merge tag 'pinctrl-v6.19-2' of git://git.kern..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10e6b1fc580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=a11e0f726bfb6765
dashboard link: https://syzkaller.appspot.com/bug?extid=b4a2af3000eaa84d95d5
compiler:       gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=1513583a580000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [btrfs?] general protection fault in create_empty_buffers (5)

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
general protection fault in create_empty_buffers

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 UID: 0 PID: 6871 Comm: syz.0.175 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:create_empty_buffers+0x4d/0x480 fs/buffer.c:1694
Code: ea 6d ff 48 89 de ba 40 8c 40 00 4c 89 ef e8 0a f6 ff ff 49 89 c6 48 89 c3 eb 03 48 89 c3 e8 1a ea 6d ff 48 89 d8 48 c1 e8 03 <80> 3c 28 00 0f 85 81 03 00 00 48 8d 7b 08 4c 09 23 48 89 f8 48 c1
RSP: 0018:ffffc90003967870 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8250f9bc
RDX: ffff888025ef8000 RSI: ffffffff8250fe96 RDI: ffff888025ef9680
RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: ffff888025ef8b30 R12: 0000000000000000
R13: ffffea0000a94200 R14: 0000000000000000 R15: dffffc0000000000
FS:  00007fe24bca76c0(0000) GS:ffff8880d68f5000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe24bca6f98 CR3: 0000000035a6c000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 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+0x201/0x580 fs/btrfs/volumes.c:1371
 btrfs_scan_one_device+0x109/0x820 fs/btrfs/volumes.c:1479
 btrfs_get_tree_super fs/btrfs/super.c:1860 [inline]
 btrfs_get_tree_subvol fs/btrfs/super.c:2089 [inline]
 btrfs_get_tree+0x5b3/0x2710 fs/btrfs/super.c:2123
 vfs_get_tree+0x8e/0x330 fs/super.c:1751
 fc_mount fs/namespace.c:1199 [inline]
 do_new_mount_fc fs/namespace.c:3636 [inline]
 do_new_mount fs/namespace.c:3712 [inline]
 path_mount+0x7bf/0x23a0 fs/namespace.c:4022
 do_mount fs/namespace.c:4035 [inline]
 __do_sys_mount fs/namespace.c:4224 [inline]
 __se_sys_mount fs/namespace.c:4201 [inline]
 __x64_sys_mount+0x293/0x310 fs/namespace.c:4201
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe24ad8f7c9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe24bca7038 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007fe24afe6090 RCX: 00007fe24ad8f7c9
RDX: 00002000000000c0 RSI: 0000200000000080 RDI: 00002000000001c0
RBP: 00007fe24ae13f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000004418 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fe24afe6128 R14: 00007fe24afe6090 R15: 00007ffe2f937158
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:create_empty_buffers+0x4d/0x480 fs/buffer.c:1694
Code: ea 6d ff 48 89 de ba 40 8c 40 00 4c 89 ef e8 0a f6 ff ff 49 89 c6 48 89 c3 eb 03 48 89 c3 e8 1a ea 6d ff 48 89 d8 48 c1 e8 03 <80> 3c 28 00 0f 85 81 03 00 00 48 8d 7b 08 4c 09 23 48 89 f8 48 c1
RSP: 0018:ffffc90003967870 EFLAGS: 00010246

RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8250f9bc
RDX: ffff888025ef8000 RSI: ffffffff8250fe96 RDI: ffff888025ef9680
RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: ffff888025ef8b30 R12: 0000000000000000
R13: ffffea0000a94200 R14: 0000000000000000 R15: dffffc0000000000
FS:  00007fe24bca76c0(0000) GS:ffff8880d68f5000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe24bca6f98 CR3: 0000000035a6c000 CR4: 0000000000352ef0
----------------
Code disassembly (best guess), 1 bytes skipped:
   0:	6d                   	insl   (%dx),%es:(%rdi)
   1:	ff 48 89             	decl   -0x77(%rax)
   4:	de ba 40 8c 40 00    	fidivrs 0x408c40(%rdx)
   a:	4c 89 ef             	mov    %r13,%rdi
   d:	e8 0a f6 ff ff       	call   0xfffff61c
  12:	49 89 c6             	mov    %rax,%r14
  15:	48 89 c3             	mov    %rax,%rbx
  18:	eb 03                	jmp    0x1d
  1a:	48 89 c3             	mov    %rax,%rbx
  1d:	e8 1a ea 6d ff       	call   0xff6dea3c
  22:	48 89 d8             	mov    %rbx,%rax
  25:	48 c1 e8 03          	shr    $0x3,%rax
* 29:	80 3c 28 00          	cmpb   $0x0,(%rax,%rbp,1) <-- trapping instruction
  2d:	0f 85 81 03 00 00    	jne    0x3b4
  33:	48 8d 7b 08          	lea    0x8(%rbx),%rdi
  37:	4c 09 23             	or     %r12,(%rbx)
  3a:	48 89 f8             	mov    %rdi,%rax
  3d:	48                   	rex.W
  3e:	c1                   	.byte 0xc1


Tested on:

commit:         623fb991 Merge tag 'pinctrl-v6.19-2' of git://git.kern..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=137de922580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=a11e0f726bfb6765
dashboard link: https://syzkaller.appspot.com/bug?extid=b4a2af3000eaa84d95d5
compiler:       gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=1778a19a580000

Re: [syzbot] [btrfs?] general protection fault in create_empty_buffers (5)

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
kernel BUG in __filemap_add_folio

 kernel_clone+0xfc/0x910 kernel/fork.c:2651
 __do_sys_clone+0xce/0x120 kernel/fork.c:2792
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
------------[ cut here ]------------
kernel BUG at mm/filemap.c:858!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 2 UID: 0 PID: 6603 Comm: syz.0.90 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:__filemap_add_folio+0xf29/0x11b0 mm/filemap.c:858
Code: 96 c6 ff 48 c7 c6 80 ed 99 8b 4c 89 ef e8 bf 72 11 00 90 0f 0b e8 77 96 c6 ff 48 c7 c6 e0 ed 99 8b 4c 89 ef e8 a8 72 11 00 90 <0f> 0b e8 60 96 c6 ff 90 0f 0b 90 e9 1c fc ff ff e8 52 96 c6 ff 48
RSP: 0018:ffffc900040af808 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88802b89c980 RSI: ffffffff81f85248 RDI: ffff88802b89ce04
RBP: 0000000000000c40 R08: 0000000000000001 R09: 0000000000000001
R10: ffffffff9088b8d7 R11: 0000000000000001 R12: 0000000000000002
R13: ffffea0000936400 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f83919c36c0(0000) GS:ffff8880d6af5000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f83919c2f98 CR3: 000000002db08000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 filemap_add_folio+0x19a/0x610 mm/filemap.c:966
 do_read_cache_folio+0x23c/0x5c0 mm/filemap.c:4063
 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
 btrfs_scan_one_device+0x109/0x820 fs/btrfs/volumes.c:1475
 btrfs_get_tree_super fs/btrfs/super.c:1860 [inline]
 btrfs_get_tree_subvol fs/btrfs/super.c:2089 [inline]
 btrfs_get_tree+0x5b3/0x2710 fs/btrfs/super.c:2123
 vfs_get_tree+0x8e/0x330 fs/super.c:1751
 fc_mount fs/namespace.c:1199 [inline]
 do_new_mount_fc fs/namespace.c:3636 [inline]
 do_new_mount fs/namespace.c:3712 [inline]
 path_mount+0x7bf/0x23a0 fs/namespace.c:4022
 do_mount fs/namespace.c:4035 [inline]
 __do_sys_mount fs/namespace.c:4224 [inline]
 __se_sys_mount fs/namespace.c:4201 [inline]
 __x64_sys_mount+0x293/0x310 fs/namespace.c:4201
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f8390b8f7c9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f83919c3038 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f8390de6090 RCX: 00007f8390b8f7c9
RDX: 00002000000000c0 RSI: 0000200000000080 RDI: 00002000000001c0
RBP: 00007f8390c13f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000004418 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f8390de6128 R14: 00007f8390de6090 R15: 00007ffc2a9b3b58
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__filemap_add_folio+0xf29/0x11b0 mm/filemap.c:858
Code: 96 c6 ff 48 c7 c6 80 ed 99 8b 4c 89 ef e8 bf 72 11 00 90 0f 0b e8 77 96 c6 ff 48 c7 c6 e0 ed 99 8b 4c 89 ef e8 a8 72 11 00 90 <0f> 0b e8 60 96 c6 ff 90 0f 0b 90 e9 1c fc ff ff e8 52 96 c6 ff 48
RSP: 0018:ffffc900040af808 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88802b89c980 RSI: ffffffff81f85248 RDI: ffff88802b89ce04
RBP: 0000000000000c40 R08: 0000000000000001 R09: 0000000000000001
R10: ffffffff9088b8d7 R11: 0000000000000001 R12: 0000000000000002
R13: ffffea0000936400 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f83919c36c0(0000) GS:ffff8880d6af5000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f83919c2f98 CR3: 000000002db08000 CR4: 0000000000352ef0


Tested on:

commit:         623fb991 Merge tag 'pinctrl-v6.19-2' of git://git.kern..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15105074580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=a11e0f726bfb6765
dashboard link: https://syzkaller.appspot.com/bug?extid=b4a2af3000eaa84d95d5
compiler:       gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=10205074580000

Re: [syzbot] [btrfs?] general protection fault in create_empty_buffers (5)

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
general protection fault in create_empty_buffers

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 2 UID: 0 PID: 6551 Comm: syz.0.69 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:create_empty_buffers+0x4d/0x480 fs/buffer.c:1694
Code: ea 6d ff 48 89 de ba 40 8c 40 00 4c 89 ef e8 0a f6 ff ff 49 89 c6 48 89 c3 eb 03 48 89 c3 e8 1a ea 6d ff 48 89 d8 48 c1 e8 03 <80> 3c 28 00 0f 85 81 03 00 00 48 8d 7b 08 4c 09 23 48 89 f8 48 c1
RSP: 0018:ffffc900041ff870 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8250f9bc
RDX: ffff8880375dc980 RSI: ffffffff8250fe96 RDI: ffff8880375de000
RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: ffffea0000d84a80 R14: 0000000000000000 R15: dffffc0000000000
FS:  00007f3509bdd6c0(0000) GS:ffff8880d6af5000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f3509bdcf98 CR3: 000000002babe000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 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+0x23a/0x5c0 fs/btrfs/volumes.c:1370
 btrfs_scan_one_device+0x109/0x820 fs/btrfs/volumes.c:1478
 btrfs_get_tree_super fs/btrfs/super.c:1860 [inline]
 btrfs_get_tree_subvol fs/btrfs/super.c:2089 [inline]
 btrfs_get_tree+0x5b3/0x2710 fs/btrfs/super.c:2123
 vfs_get_tree+0x8e/0x330 fs/super.c:1751
 fc_mount fs/namespace.c:1199 [inline]
 do_new_mount_fc fs/namespace.c:3636 [inline]
 do_new_mount fs/namespace.c:3712 [inline]
 path_mount+0x7bf/0x23a0 fs/namespace.c:4022
 do_mount fs/namespace.c:4035 [inline]
 __do_sys_mount fs/namespace.c:4224 [inline]
 __se_sys_mount fs/namespace.c:4201 [inline]
 __x64_sys_mount+0x293/0x310 fs/namespace.c:4201
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f350a58f7c9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f3509bdd038 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f350a7e6090 RCX: 00007f350a58f7c9
RDX: 00002000000000c0 RSI: 0000200000000080 RDI: 00002000000001c0
RBP: 00007f350a613f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000004418 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f350a7e6128 R14: 00007f350a7e6090 R15: 00007ffc45633788
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:create_empty_buffers+0x4d/0x480 fs/buffer.c:1694
Code: ea 6d ff 48 89 de ba 40 8c 40 00 4c 89 ef e8 0a f6 ff ff 49 89 c6 48 89 c3 eb 03 48 89 c3 e8 1a ea 6d ff 48 89 d8 48 c1 e8 03 <80> 3c 28 00 0f 85 81 03 00 00 48 8d 7b 08 4c 09 23 48 89 f8 48 c1
RSP: 0018:ffffc900041ff870 EFLAGS: 00010246

RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8250f9bc
RDX: ffff8880375dc980 RSI: ffffffff8250fe96 RDI: ffff8880375de000
RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: ffffea0000d84a80 R14: 0000000000000000 R15: dffffc0000000000
FS:  00007f3509bdd6c0(0000) GS:ffff8880d6af5000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f3509bdcf98 CR3: 000000002babe000 CR4: 0000000000352ef0
----------------
Code disassembly (best guess), 1 bytes skipped:
   0:	6d                   	insl   (%dx),%es:(%rdi)
   1:	ff 48 89             	decl   -0x77(%rax)
   4:	de ba 40 8c 40 00    	fidivrs 0x408c40(%rdx)
   a:	4c 89 ef             	mov    %r13,%rdi
   d:	e8 0a f6 ff ff       	call   0xfffff61c
  12:	49 89 c6             	mov    %rax,%r14
  15:	48 89 c3             	mov    %rax,%rbx
  18:	eb 03                	jmp    0x1d
  1a:	48 89 c3             	mov    %rax,%rbx
  1d:	e8 1a ea 6d ff       	call   0xff6dea3c
  22:	48 89 d8             	mov    %rbx,%rax
  25:	48 c1 e8 03          	shr    $0x3,%rax
* 29:	80 3c 28 00          	cmpb   $0x0,(%rax,%rbp,1) <-- trapping instruction
  2d:	0f 85 81 03 00 00    	jne    0x3b4
  33:	48 8d 7b 08          	lea    0x8(%rbx),%rdi
  37:	4c 09 23             	or     %r12,(%rbx)
  3a:	48 89 f8             	mov    %rdi,%rax
  3d:	48                   	rex.W
  3e:	c1                   	.byte 0xc1


Tested on:

commit:         623fb991 Merge tag 'pinctrl-v6.19-2' of git://git.kern..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15ed319a580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=a11e0f726bfb6765
dashboard link: https://syzkaller.appspot.com/bug?extid=b4a2af3000eaa84d95d5
compiler:       gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=16e55f92580000