[syzbot] [block?] general protection fault in bio_alloc_bioset

[syzbot] [block?] general protection fault in bio_alloc_bioset

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    8e42d2514a7e Add linux-next specific files for 20260318
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10b35ed6580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=1da705b17f2649a3
dashboard link: https://syzkaller.appspot.com/bug?extid=09ddb593eea76a158f42
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1325a06a580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/64c940773401/disk-8e42d251.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/aa7a94376665/vmlinux-8e42d251.xz
kernel image: https://storage.googleapis.com/syzbot-assets/5a7ab603c859/bzImage-8e42d251.xz

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

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 UID: 0 PID: 1116 Comm: kworker/u8:9 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
Workqueue: writeback wb_workfn (flush-8:0)
RIP: 0010:bio_init block/bio.c:214 [inline]
RIP: 0010:bio_init_inline include/linux/bio.h:435 [inline]
RIP: 0010:bio_alloc_bioset+0x664/0xc10 block/bio.c:593
Code: 04 24 00 00 00 00 41 8d 46 ff 0f b7 d8 bf 04 00 00 00 89 de e8 6d b0 3a fd 66 83 fb 04 0f 83 db 00 00 00 4c 89 f8 48 c1 e8 03 <80> 3c 28 00 74 08 4c 89 ff e8 3e 27 a4 fd 49 c7 07 00 00 00 00 49
RSP: 0000:ffffc9000576efe8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88802998bd00 RSI: 0000000000000000 RDI: 0000000000000004
RBP: dffffc0000000000 R08: ffffffff905435f7 R09: 1ffffffff20a86be
R10: dffffc0000000000 R11: fffffbfff20a86bf R12: 0000000000092800
R13: ffffffff9a8dc840 R14: 0000000000000001 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff888124de1000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f51b88511d0 CR3: 0000000072570000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 bio_alloc include/linux/bio.h:373 [inline]
 submit_bh_wbc+0x22d/0x650 fs/buffer.c:2816
 __block_write_full_folio+0x810/0xe10 fs/buffer.c:1930
 blkdev_writepages+0xef/0x1b0 block/fops.c:486
 do_writepages+0x32e/0x550 mm/page-writeback.c:2554
 __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750
 writeback_sb_inodes+0x992/0x1a20 fs/fs-writeback.c:2042
 __writeback_inodes_wb+0x111/0x240 fs/fs-writeback.c:2118
 wb_writeback+0x46a/0xb70 fs/fs-writeback.c:2229
 wb_check_start_all fs/fs-writeback.c:2355 [inline]
 wb_do_writeback fs/fs-writeback.c:2381 [inline]
 wb_workfn+0x95b/0xf50 fs/fs-writeback.c:2414
 process_one_work+0x9ab/0x1780 kernel/workqueue.c:3288
 process_scheduled_works kernel/workqueue.c:3379 [inline]
 worker_thread+0xba8/0x11e0 kernel/workqueue.c:3465
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:bio_init block/bio.c:214 [inline]
RIP: 0010:bio_init_inline include/linux/bio.h:435 [inline]
RIP: 0010:bio_alloc_bioset+0x664/0xc10 block/bio.c:593
Code: 04 24 00 00 00 00 41 8d 46 ff 0f b7 d8 bf 04 00 00 00 89 de e8 6d b0 3a fd 66 83 fb 04 0f 83 db 00 00 00 4c 89 f8 48 c1 e8 03 <80> 3c 28 00 74 08 4c 89 ff e8 3e 27 a4 fd 49 c7 07 00 00 00 00 49
RSP: 0000:ffffc9000576efe8 EFLAGS: 00010246

RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88802998bd00 RSI: 0000000000000000 RDI: 0000000000000004
RBP: dffffc0000000000 R08: ffffffff905435f7 R09: 1ffffffff20a86be
R10: dffffc0000000000 R11: fffffbfff20a86bf R12: 0000000000092800
R13: ffffffff9a8dc840 R14: 0000000000000001 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff888124de1000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000564154e50330 CR3: 000000005d868000 CR4: 00000000003526f0
----------------
Code disassembly (best guess):
   0:	04 24                	add    $0x24,%al
   2:	00 00                	add    %al,(%rax)
   4:	00 00                	add    %al,(%rax)
   6:	41 8d 46 ff          	lea    -0x1(%r14),%eax
   a:	0f b7 d8             	movzwl %ax,%ebx
   d:	bf 04 00 00 00       	mov    $0x4,%edi
  12:	89 de                	mov    %ebx,%esi
  14:	e8 6d b0 3a fd       	call   0xfd3ab086
  19:	66 83 fb 04          	cmp    $0x4,%bx
  1d:	0f 83 db 00 00 00    	jae    0xfe
  23:	4c 89 f8             	mov    %r15,%rax
  26:	48 c1 e8 03          	shr    $0x3,%rax
* 2a:	80 3c 28 00          	cmpb   $0x0,(%rax,%rbp,1) <-- trapping instruction
  2e:	74 08                	je     0x38
  30:	4c 89 ff             	mov    %r15,%rdi
  33:	e8 3e 27 a4 fd       	call   0xfda42776
  38:	49 c7 07 00 00 00 00 	movq   $0x0,(%r15)
  3f:	49                   	rex.WB


---
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] [block?] general protection fault in bio_alloc_bioset

[Edward Adam Davis]

#syz test

diff --git a/block/bio.c b/block/bio.c
index 5057047194c4..bbbcd1d2f85d 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -530,11 +530,13 @@ struct bio *bio_alloc_bioset(struct block_device *bdev, unsigned short nr_vecs,
 	struct bio *bio = NULL;
 	gfp_t saved_gfp = gfp;
 	void *p;
+	static DEFINE_MUTEX(bio_alloc_lock);
 
 	/* should not use nobvec bioset for nr_vecs > 0 */
 	if (WARN_ON_ONCE(!mempool_initialized(&bs->bvec_pool) && nr_vecs > 0))
 		return NULL;
 
+	mutex_lock(&bio_alloc_lock);
 	gfp = try_alloc_gfp(gfp);
 	if (bs->cache && nr_vecs <= BIO_INLINE_VECS) {
 		/*
@@ -570,8 +572,10 @@ struct bio *bio_alloc_bioset(struct block_device *bdev, unsigned short nr_vecs,
 		 * Give up if we are not allow to sleep as non-blocking mempool
 		 * allocations just go back to the slab allocation.
 		 */
-		if (!(saved_gfp & __GFP_DIRECT_RECLAIM))
+		if (!(saved_gfp & __GFP_DIRECT_RECLAIM)) {
+			mutex_unlock(&bio_alloc_lock);
 			return NULL;
+		}
 
 		punt_bios_to_rescuer(bs);
 
@@ -594,6 +598,7 @@ struct bio *bio_alloc_bioset(struct block_device *bdev, unsigned short nr_vecs,
 	else
 		bio_init(bio, bdev, bvecs, nr_vecs, opf);
 	bio->bi_pool = bs;
+	mutex_unlock(&bio_alloc_lock);
 	return bio;
 }
 EXPORT_SYMBOL(bio_alloc_bioset);

Re: [syzbot] [block?] general protection fault in bio_alloc_bioset

[syzbot]

Hello,

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

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 UID: 0 PID: 5172 Comm: jbd2/sda1-8 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
RIP: 0010:bio_init block/bio.c:214 [inline]
RIP: 0010:bio_init_inline include/linux/bio.h:435 [inline]
RIP: 0010:bio_alloc_bioset+0x67e/0xc30 block/bio.c:597
Code: 04 24 00 00 00 00 41 8d 46 ff 0f b7 d8 bf 04 00 00 00 89 de e8 33 6c 3c fd 66 83 fb 04 0f 83 db 00 00 00 4c 89 f8 48 c1 e8 03 <80> 3c 28 00 74 08 4c 89 ff e8 c4 cf a5 fd 49 c7 07 00 00 00 00 49
RSP: 0018:ffffc9000e6ef7e8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88803778bd00 RSI: 0000000000000000 RDI: 0000000000000004
RBP: dffffc0000000000 R08: ffffffff903445f7 R09: 1ffffffff20688be
R10: dffffc0000000000 R11: fffffbfff20688bf R12: 0000000000092800
R13: ffffffff9a6ca840 R14: 0000000000000001 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff888124ff3000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2f6b59c76f CR3: 000000007cd28000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 bio_alloc include/linux/bio.h:373 [inline]
 submit_bh_wbc+0x22d/0x650 fs/buffer.c:2816
 jbd2_journal_commit_transaction+0x2186/0x5ad0 fs/jbd2/commit.c:726
 kjournald2+0x3e0/0x760 fs/jbd2/journal.c:201
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:bio_init block/bio.c:214 [inline]
RIP: 0010:bio_init_inline include/linux/bio.h:435 [inline]
RIP: 0010:bio_alloc_bioset+0x67e/0xc30 block/bio.c:597
Code: 04 24 00 00 00 00 41 8d 46 ff 0f b7 d8 bf 04 00 00 00 89 de e8 33 6c 3c fd 66 83 fb 04 0f 83 db 00 00 00 4c 89 f8 48 c1 e8 03 <80> 3c 28 00 74 08 4c 89 ff e8 c4 cf a5 fd 49 c7 07 00 00 00 00 49
RSP: 0018:ffffc9000e6ef7e8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88803778bd00 RSI: 0000000000000000 RDI: 0000000000000004
RBP: dffffc0000000000 R08: ffffffff903445f7 R09: 1ffffffff20688be
R10: dffffc0000000000 R11: fffffbfff20688bf R12: 0000000000092800
R13: ffffffff9a6ca840 R14: 0000000000000001 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff888124ff3000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2f6b59c76f CR3: 000000007cd28000 CR4: 00000000003526f0
----------------
Code disassembly (best guess):
   0:	04 24                	add    $0x24,%al
   2:	00 00                	add    %al,(%rax)
   4:	00 00                	add    %al,(%rax)
   6:	41 8d 46 ff          	lea    -0x1(%r14),%eax
   a:	0f b7 d8             	movzwl %ax,%ebx
   d:	bf 04 00 00 00       	mov    $0x4,%edi
  12:	89 de                	mov    %ebx,%esi
  14:	e8 33 6c 3c fd       	call   0xfd3c6c4c
  19:	66 83 fb 04          	cmp    $0x4,%bx
  1d:	0f 83 db 00 00 00    	jae    0xfe
  23:	4c 89 f8             	mov    %r15,%rax
  26:	48 c1 e8 03          	shr    $0x3,%rax
* 2a:	80 3c 28 00          	cmpb   $0x0,(%rax,%rbp,1) <-- trapping instruction
  2e:	74 08                	je     0x38
  30:	4c 89 ff             	mov    %r15,%rdi
  33:	e8 c4 cf a5 fd       	call   0xfda5cffc
  38:	49 c7 07 00 00 00 00 	movq   $0x0,(%r15)
  3f:	49                   	rex.WB


Tested on:

commit:         785f0eb2 Add linux-next specific files for 20260320
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1646d0ca580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=22bf3527036b9be1
dashboard link: https://syzkaller.appspot.com/bug?extid=09ddb593eea76a158f42
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=1177a2f6580000

Re: [syzbot] [block?] general protection fault in bio_alloc_bioset

[Edward Adam Davis]

#syz test

diff --git a/block/bio.c b/block/bio.c
index 5057047194c4..0a870979bd41 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -582,6 +582,9 @@ struct bio *bio_alloc_bioset(struct block_device *bdev, unsigned short nr_vecs,
 		opf &= ~REQ_ALLOC_CACHE;
 
 		p = mempool_alloc(&bs->bio_pool, gfp);
+		if (unlikely(!p))
+			return NULL;
+
 		bio = p + bs->front_pad;
 		if (nr_vecs > BIO_INLINE_VECS) {
 			nr_vecs = BIO_MAX_VECS;

Re: [syzbot] [block?] general protection fault in bio_alloc_bioset

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
SYZFAIL: failed to recv rpc

SYZFAIL: failed to recv rpc
fd=3 want=4 recv=0 n=0 (errno 9: Bad file descriptor)


Tested on:

commit:         785f0eb2 Add linux-next specific files for 20260320
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17384d72580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=22bf3527036b9be1
dashboard link: https://syzkaller.appspot.com/bug?extid=09ddb593eea76a158f42
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=13e00b52580000

[PATCH next] block: mempool alloc fail due to insufficient memory

[Edward Adam Davis]

Add a failure check for mempool_alloc() in the slowpath.

[1]
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
Workqueue: writeback wb_workfn (flush-8:0)
RIP: 0010:bio_init block/bio.c:214 [inline]
RIP: 0010:bio_init_inline include/linux/bio.h:435 [inline]
RIP: 0010:bio_alloc_bioset+0x664/0xc10 block/bio.c:593
Call Trace:
 bio_alloc include/linux/bio.h:373 [inline]
 submit_bh_wbc+0x22d/0x650 fs/buffer.c:2816

Fixes: b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath")
Reported-by: syzbot+09ddb593eea76a158f42@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=09ddb593eea76a158f42
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
 block/bio.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/block/bio.c b/block/bio.c
index 5057047194c4..0a870979bd41 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -582,6 +582,9 @@ struct bio *bio_alloc_bioset(struct block_device *bdev, unsigned short nr_vecs,
 		opf &= ~REQ_ALLOC_CACHE;
 
 		p = mempool_alloc(&bs->bio_pool, gfp);
+		if (unlikely(!p))
+			return NULL;
+
 		bio = p + bs->front_pad;
 		if (nr_vecs > BIO_INLINE_VECS) {
 			nr_vecs = BIO_MAX_VECS;
-- 
2.43.0

Re: [PATCH next] block: mempool alloc fail due to insufficient memory

[Jens Axboe]

On 3/21/26 2:36 AM, Edward Adam Davis wrote:
> Add a failure check for mempool_alloc() in the slowpath.
> 
> [1]
> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
> Workqueue: writeback wb_workfn (flush-8:0)
> RIP: 0010:bio_init block/bio.c:214 [inline]
> RIP: 0010:bio_init_inline include/linux/bio.h:435 [inline]
> RIP: 0010:bio_alloc_bioset+0x664/0xc10 block/bio.c:593
> Call Trace:
>  bio_alloc include/linux/bio.h:373 [inline]
>  submit_bh_wbc+0x22d/0x650 fs/buffer.c:2816
> 
> Fixes: b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath")
> Reported-by: syzbot+09ddb593eea76a158f42@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=09ddb593eea76a158f42
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
>  block/bio.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/block/bio.c b/block/bio.c
> index 5057047194c4..0a870979bd41 100644
> --- a/block/bio.c
> +++ b/block/bio.c
> @@ -582,6 +582,9 @@ struct bio *bio_alloc_bioset(struct block_device *bdev, unsigned short nr_vecs,
>  		opf &= ~REQ_ALLOC_CACHE;
>  
>  		p = mempool_alloc(&bs->bio_pool, gfp);
> +		if (unlikely(!p))
> +			return NULL;
> +

Doesn't look right at all. You dropped the backtrace, which shows this is
off __block_write_full_folio() -> submit_bh_wbc() which allocates a bio
from the mempool with GFP_NOIO. That should allow blocking, and hence
mempool_alloc() should NEVER return NULL for that case. If it does,
it's broken, and your change is just papering around that issue.

-- 
Jens Axboe

Re: [syzbot] [block?] general protection fault in bio_alloc_bioset

[Vasily Gorbik]

#syz test

diff --git a/block/bio.c b/block/bio.c
index 5057047194c4..77067fa346d3 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -581,11 +581,11 @@ struct bio *bio_alloc_bioset(struct block_device *bdev, unsigned short nr_vecs,
 		 */
 		opf &= ~REQ_ALLOC_CACHE;
 
-		p = mempool_alloc(&bs->bio_pool, gfp);
+		p = mempool_alloc(&bs->bio_pool, saved_gfp);
 		bio = p + bs->front_pad;
 		if (nr_vecs > BIO_INLINE_VECS) {
 			nr_vecs = BIO_MAX_VECS;
-			bvecs = mempool_alloc(&bs->bvec_pool, gfp);
+			bvecs = mempool_alloc(&bs->bvec_pool, saved_gfp);
 		}
 	}
 
-- 
2.53.0

Re: [syzbot] [block?] general protection fault in bio_alloc_bioset

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
SYZFAIL: failed to recv rpc

SYZFAIL: failed to recv rpc
fd=3 want=4 recv=0 n=0 (errno 9: Bad file descriptor)


Tested on:

commit:         785f0eb2 Add linux-next specific files for 20260320
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1385ccba580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=22bf3527036b9be1
dashboard link: https://syzkaller.appspot.com/bug?extid=09ddb593eea76a158f42
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=143881d6580000

Re: [syzbot] [block?] general protection fault in bio_alloc_bioset

[Vasily Gorbik]

On Sat, Mar 21, 2026 at 05:18:01PM -0700, syzbot wrote:
> Hello,
> 
> syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> SYZFAIL: failed to recv rpc
> 
> SYZFAIL: failed to recv rpc
> fd=3 want=4 recv=0 n=0 (errno 9: Bad file descriptor)
> 
> 
> Tested on:
> 
> commit:         785f0eb2 Add linux-next specific files for 20260320
> git tree:       linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1385ccba580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=22bf3527036b9be1
> dashboard link: https://syzkaller.appspot.com/bug?extid=09ddb593eea76a158f42
> compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
> patch:          https://syzkaller.appspot.com/x/patch.diff?x=143881d6580000

Well, keeping in mind that the repro does

ioctl$BLKTRACESETUP(r1, 0xc0481273, &(0x7f00000001c0)={'\x00', 0x1, 0x18148795, 0x7, 0x6})

that is roughly 2.6 GiB per CPU of relay buffer on an ~8 GiB VM with tiny
swap. Surviving 1h15m before syzbot loses it is about as good as it gets.

[PATCH] block: fix bio_alloc_bioset slowpath GFP handling

[Vasily Gorbik]

bio_alloc_bioset() first strips __GFP_DIRECT_RECLAIM from the optimistic
fast allocation attempt with try_alloc_gfp(). If that fast path fails,
the slowpath checks saved_gfp to decide whether blocking allocation is
allowed, but then still calls mempool_alloc() with the stripped gfp mask.
That can lead to a NULL bio pointer being passed into bio_init().

Fix the slowpath by using saved_gfp for the bio and bvec mempool
allocations.

Fixes: b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath")
Reported-by: syzbot+09ddb593eea76a158f42@syzkaller.appspotmail.com
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
---
If this looks fine, feel free to squash it into the offending commit or
pick it up separately.

 block/bio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index 5057047194c4..77067fa346d3 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -581,11 +581,11 @@ struct bio *bio_alloc_bioset(struct block_device *bdev, unsigned short nr_vecs,
 		 */
 		opf &= ~REQ_ALLOC_CACHE;
 
-		p = mempool_alloc(&bs->bio_pool, gfp);
+		p = mempool_alloc(&bs->bio_pool, saved_gfp);
 		bio = p + bs->front_pad;
 		if (nr_vecs > BIO_INLINE_VECS) {
 			nr_vecs = BIO_MAX_VECS;
-			bvecs = mempool_alloc(&bs->bvec_pool, gfp);
+			bvecs = mempool_alloc(&bs->bvec_pool, saved_gfp);
 		}
 	}
 
-- 
2.53.0

Re: [PATCH] block: fix bio_alloc_bioset slowpath GFP handling

[Christoph Hellwig]

On Sun, Mar 22, 2026 at 03:35:10AM +0100, Vasily Gorbik wrote:
> bio_alloc_bioset() first strips __GFP_DIRECT_RECLAIM from the optimistic
> fast allocation attempt with try_alloc_gfp(). If that fast path fails,
> the slowpath checks saved_gfp to decide whether blocking allocation is
> allowed, but then still calls mempool_alloc() with the stripped gfp mask.
> That can lead to a NULL bio pointer being passed into bio_init().
> 
> Fix the slowpath by using saved_gfp for the bio and bvec mempool
> allocations.

Looks good, thanks:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH] block: fix bio_alloc_bioset slowpath GFP handling

[Jens Axboe]

On Sun, 22 Mar 2026 03:35:10 +0100, Vasily Gorbik wrote:
> bio_alloc_bioset() first strips __GFP_DIRECT_RECLAIM from the optimistic
> fast allocation attempt with try_alloc_gfp(). If that fast path fails,
> the slowpath checks saved_gfp to decide whether blocking allocation is
> allowed, but then still calls mempool_alloc() with the stripped gfp mask.
> That can lead to a NULL bio pointer being passed into bio_init().
> 
> Fix the slowpath by using saved_gfp for the bio and bvec mempool
> allocations.
> 
> [...]

Applied, thanks!

[1/1] block: fix bio_alloc_bioset slowpath GFP handling
      commit: 67807fbaf12719fca46a622d759484652b79c7c3

Best regards,
-- 
Jens Axboe