The Linux Kernel Mailing List
 help / color / mirror / Atom feed
* [syzbot] [bridge?] kernel BUG in __get_vm_area_node
@ 2026-05-09 19:35 syzbot
  2026-05-12  8:47 ` Ido Schimmel
  0 siblings, 1 reply; 4+ messages in thread
From: syzbot @ 2026-05-09 19:35 UTC (permalink / raw)
  To: bridge, davem, edumazet, horms, idosch, kuba, linux-kernel,
	netdev, pabeni, razor, syzkaller-bugs

Hello,

syzbot found the following issue on:

HEAD commit:    9207d47f966b Merge tag 'for-linus' of git://git.kernel.org..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17e44d06580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=d0f0911eedbc130a
dashboard link: https://syzkaller.appspot.com/bug?extid=8b12fc6e0fb139765b58
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
userspace arch: i386

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-9207d47f.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/6c5e883f31aa/vmlinux-9207d47f.xz
kernel image: https://storage.googleapis.com/syzbot-assets/19f3e863ae5c/bzImage-9207d47f.xz

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

------------[ cut here ]------------
kernel BUG at mm/vmalloc.c:3206!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 1 UID: 0 PID: 8030 Comm: syz.6.9336 Tainted: G             L      syzkaller #0 PREEMPT(full) 
Tainted: [L]=SOFTLOCKUP
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:__get_vm_area_node+0x2d2/0x330 mm/vmalloc.c:3206
Code: 03 80 3c 11 00 75 5c 48 89 43 08 e9 4b ff ff ff e8 43 a8 a4 ff 48 89 df e8 db 98 05 00 31 db e9 37 ff ff ff e8 2f a8 a4 ff 90 <0f> 0b e8 77 6b 11 00 e9 9e fe ff ff e8 6d 6b 11 00 e9 71 fe ff ff
RSP: 0018:ffffc90006f76860 EFLAGS: 00010246
RAX: 0000000000080000 RBX: 0000000000000200 RCX: ffffc90034405000
RDX: 0000000000080000 RSI: ffffffff82633fb1 RDI: ffff8880244b4a00
RBP: 000000000000000c R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000200 R11: 0000000000000000 R12: 0000000000000022
R13: 0000000000008080 R14: 0000000000000001 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88809727d000(0063) knlGS:00000000f4f61b40
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000f73c4f50 CR3: 0000000055b77000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 000000000000000e DR6: 00000000ffff0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 __vmalloc_node_range_noprof+0x228/0x1630 mm/vmalloc.c:4024
 __kvmalloc_node_noprof+0x3de/0xa00 mm/slub.c:6860
 bucket_table_alloc.isra.0+0x88/0x460 lib/rhashtable.c:186
 rhashtable_insert_rehash lib/rhashtable.c:493 [inline]
 rhashtable_try_insert lib/rhashtable.c:661 [inline]
 rhashtable_insert_slow+0x16ab/0x1de0 lib/rhashtable.c:674
 __rhashtable_insert_fast include/linux/rhashtable.h:788 [inline]
 rhashtable_lookup_insert_fast include/linux/rhashtable.h:965 [inline]
 fdb_create+0x13cf/0x1920 net/bridge/br_fdb.c:415
 fdb_add_local net/bridge/br_fdb.c:450 [inline]
 fdb_add_local+0x155/0x1c0 net/bridge/br_fdb.c:430
 br_fdb_add_local+0x39/0x60 net/bridge/br_fdb.c:960
 __vlan_add+0x17f3/0x2e10 net/bridge/br_vlan.c:340
 br_vlan_add+0x2dc/0xa00 net/bridge/br_vlan.c:810
 __vlan_add+0xf7c/0x2e10 net/bridge/br_vlan.c:297
 nbp_vlan_add+0x258/0x3e0 net/bridge/br_vlan.c:1348
 br_vlan_info+0x159/0x3d0 net/bridge/br_netlink.c:705
 br_process_vlan_info+0x404/0x8f0 net/bridge/br_netlink.c:768
 br_afspec+0x422/0x650 net/bridge/br_netlink.c:836
 br_setlink+0x376/0x630 net/bridge/br_netlink.c:1135
 rtnl_bridge_setlink+0x56d/0x740 net/core/rtnetlink.c:5571
 rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:7004
 netlink_rcv_skb+0x159/0x420 net/netlink/af_netlink.c:2550
 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
 netlink_unicast+0x585/0x850 net/netlink/af_netlink.c:1344
 netlink_sendmsg+0x8b0/0xda0 net/netlink/af_netlink.c:1894
 sock_sendmsg_nosec net/socket.c:787 [inline]
 __sock_sendmsg net/socket.c:802 [inline]
 ____sys_sendmsg+0x9e1/0xb70 net/socket.c:2698
 ___sys_sendmsg+0x190/0x1e0 net/socket.c:2752
 __sys_sendmsg+0x170/0x220 net/socket.c:2784
 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
 __do_fast_syscall_32+0xe7/0x950 arch/x86/entry/syscall_32.c:307
 do_fast_syscall_32+0x32/0x70 arch/x86/entry/syscall_32.c:332
 entry_SYSENTER_compat_after_hwframe+0x84/0x8e
RIP: 0023:0xf7f08fcc
Code: d2 74 05 c1 e8 0c 89 02 8b 5d fc 31 c0 c9 c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 2e 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 58 b8
RSP: 002b:00000000f4f6150c EFLAGS: 00000292 ORIG_RAX: 0000000000000172
RAX: ffffffffffffffda RBX: 000000000000000c RCX: 0000000080000040
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000292 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__get_vm_area_node+0x2d2/0x330 mm/vmalloc.c:3206
Code: 03 80 3c 11 00 75 5c 48 89 43 08 e9 4b ff ff ff e8 43 a8 a4 ff 48 89 df e8 db 98 05 00 31 db e9 37 ff ff ff e8 2f a8 a4 ff 90 <0f> 0b e8 77 6b 11 00 e9 9e fe ff ff e8 6d 6b 11 00 e9 71 fe ff ff
RSP: 0018:ffffc90006f76860 EFLAGS: 00010246
RAX: 0000000000080000 RBX: 0000000000000200 RCX: ffffc90034405000
RDX: 0000000000080000 RSI: ffffffff82633fb1 RDI: ffff8880244b4a00
RBP: 000000000000000c R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000200 R11: 0000000000000000 R12: 0000000000000022
R13: 0000000000008080 R14: 0000000000000001 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88809727d000(0063) knlGS:00000000f4f61b40
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000f73c4f50 CR3: 0000000055b77000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 000000000000000e DR6: 00000000ffff0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
   0:	d2 74 05 c1          	shlb   %cl,-0x3f(%rbp,%rax,1)
   4:	e8 0c 89 02 8b       	call   0x8b028915
   9:	5d                   	pop    %rbp
   a:	fc                   	cld
   b:	31 c0                	xor    %eax,%eax
   d:	c9                   	leave
   e:	c3                   	ret
   f:	90                   	nop
  10:	90                   	nop
  11:	90                   	nop
  12:	90                   	nop
  13:	90                   	nop
  14:	90                   	nop
  15:	90                   	nop
  16:	90                   	nop
  17:	90                   	nop
  18:	90                   	nop
  19:	90                   	nop
  1a:	90                   	nop
  1b:	90                   	nop
  1c:	90                   	nop
  1d:	90                   	nop
  1e:	0f 1f 00             	nopl   (%rax)
  21:	51                   	push   %rcx
  22:	52                   	push   %rdx
  23:	55                   	push   %rbp
  24:	89 e5                	mov    %esp,%ebp
  26:	0f 34                	sysenter
  28:	cd 80                	int    $0x80
* 2a:	5d                   	pop    %rbp <-- trapping instruction
  2b:	5a                   	pop    %rdx
  2c:	59                   	pop    %rcx
  2d:	c3                   	ret
  2e:	90                   	nop
  2f:	2e 8d b4 26 00 00 00 	cs lea 0x0(%rsi,%riz,1),%esi
  36:	00
  37:	8d b4 26 00 00 00 00 	lea    0x0(%rsi,%riz,1),%esi
  3e:	58                   	pop    %rax
  3f:	b8                   	.byte 0xb8


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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [syzbot] [bridge?] kernel BUG in __get_vm_area_node
  2026-05-09 19:35 [syzbot] [bridge?] kernel BUG in __get_vm_area_node syzbot
@ 2026-05-12  8:47 ` Ido Schimmel
  2026-05-12  9:26   ` Uladzislau Rezki
  0 siblings, 1 reply; 4+ messages in thread
From: Ido Schimmel @ 2026-05-12  8:47 UTC (permalink / raw)
  To: syzbot, urezki
  Cc: bridge, davem, edumazet, horms, kuba, linux-kernel, netdev,
	pabeni, razor, syzkaller-bugs, fw

On Sat, May 09, 2026 at 12:35:24PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    9207d47f966b Merge tag 'for-linus' of git://git.kernel.org..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17e44d06580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=d0f0911eedbc130a
> dashboard link: https://syzkaller.appspot.com/bug?extid=8b12fc6e0fb139765b58
> compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> userspace arch: i386
> 
> Unfortunately, I don't have any reproducer for this issue yet.
> 
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-9207d47f.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/6c5e883f31aa/vmlinux-9207d47f.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/19f3e863ae5c/bzImage-9207d47f.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+8b12fc6e0fb139765b58@syzkaller.appspotmail.com
> 
> ------------[ cut here ]------------
> kernel BUG at mm/vmalloc.c:3206!

It seems that this bug was fixed by commit 30c19366636f ("mm: fix BUG
splat with kvmalloc + GFP_ATOMIC"), but then commit c6307674ed82 ("mm:
kvmalloc: add non-blocking support for vmalloc") re-introduced it.

Uladzislau, can you please look into it?

Note that the bridge is calling rhashtable_lookup_insert_fast() with BH
disabled.

Thanks

> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
> CPU: 1 UID: 0 PID: 8030 Comm: syz.6.9336 Tainted: G             L      syzkaller #0 PREEMPT(full) 
> Tainted: [L]=SOFTLOCKUP
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> RIP: 0010:__get_vm_area_node+0x2d2/0x330 mm/vmalloc.c:3206
> Code: 03 80 3c 11 00 75 5c 48 89 43 08 e9 4b ff ff ff e8 43 a8 a4 ff 48 89 df e8 db 98 05 00 31 db e9 37 ff ff ff e8 2f a8 a4 ff 90 <0f> 0b e8 77 6b 11 00 e9 9e fe ff ff e8 6d 6b 11 00 e9 71 fe ff ff
> RSP: 0018:ffffc90006f76860 EFLAGS: 00010246
> RAX: 0000000000080000 RBX: 0000000000000200 RCX: ffffc90034405000
> RDX: 0000000000080000 RSI: ffffffff82633fb1 RDI: ffff8880244b4a00
> RBP: 000000000000000c R08: 0000000000000005 R09: 0000000000000000
> R10: 0000000000000200 R11: 0000000000000000 R12: 0000000000000022
> R13: 0000000000008080 R14: 0000000000000001 R15: 0000000000000000
> FS:  0000000000000000(0000) GS:ffff88809727d000(0063) knlGS:00000000f4f61b40
> CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
> CR2: 00000000f73c4f50 CR3: 0000000055b77000 CR4: 0000000000352ef0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 000000000000000e DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Call Trace:
>  <TASK>
>  __vmalloc_node_range_noprof+0x228/0x1630 mm/vmalloc.c:4024
>  __kvmalloc_node_noprof+0x3de/0xa00 mm/slub.c:6860
>  bucket_table_alloc.isra.0+0x88/0x460 lib/rhashtable.c:186
>  rhashtable_insert_rehash lib/rhashtable.c:493 [inline]
>  rhashtable_try_insert lib/rhashtable.c:661 [inline]
>  rhashtable_insert_slow+0x16ab/0x1de0 lib/rhashtable.c:674
>  __rhashtable_insert_fast include/linux/rhashtable.h:788 [inline]
>  rhashtable_lookup_insert_fast include/linux/rhashtable.h:965 [inline]
>  fdb_create+0x13cf/0x1920 net/bridge/br_fdb.c:415
>  fdb_add_local net/bridge/br_fdb.c:450 [inline]
>  fdb_add_local+0x155/0x1c0 net/bridge/br_fdb.c:430
>  br_fdb_add_local+0x39/0x60 net/bridge/br_fdb.c:960
>  __vlan_add+0x17f3/0x2e10 net/bridge/br_vlan.c:340
>  br_vlan_add+0x2dc/0xa00 net/bridge/br_vlan.c:810
>  __vlan_add+0xf7c/0x2e10 net/bridge/br_vlan.c:297
>  nbp_vlan_add+0x258/0x3e0 net/bridge/br_vlan.c:1348
>  br_vlan_info+0x159/0x3d0 net/bridge/br_netlink.c:705
>  br_process_vlan_info+0x404/0x8f0 net/bridge/br_netlink.c:768
>  br_afspec+0x422/0x650 net/bridge/br_netlink.c:836
>  br_setlink+0x376/0x630 net/bridge/br_netlink.c:1135
>  rtnl_bridge_setlink+0x56d/0x740 net/core/rtnetlink.c:5571
>  rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:7004
>  netlink_rcv_skb+0x159/0x420 net/netlink/af_netlink.c:2550
>  netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
>  netlink_unicast+0x585/0x850 net/netlink/af_netlink.c:1344
>  netlink_sendmsg+0x8b0/0xda0 net/netlink/af_netlink.c:1894
>  sock_sendmsg_nosec net/socket.c:787 [inline]
>  __sock_sendmsg net/socket.c:802 [inline]
>  ____sys_sendmsg+0x9e1/0xb70 net/socket.c:2698
>  ___sys_sendmsg+0x190/0x1e0 net/socket.c:2752
>  __sys_sendmsg+0x170/0x220 net/socket.c:2784
>  do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
>  __do_fast_syscall_32+0xe7/0x950 arch/x86/entry/syscall_32.c:307
>  do_fast_syscall_32+0x32/0x70 arch/x86/entry/syscall_32.c:332
>  entry_SYSENTER_compat_after_hwframe+0x84/0x8e
> RIP: 0023:0xf7f08fcc
> Code: d2 74 05 c1 e8 0c 89 02 8b 5d fc 31 c0 c9 c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 2e 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 58 b8
> RSP: 002b:00000000f4f6150c EFLAGS: 00000292 ORIG_RAX: 0000000000000172
> RAX: ffffffffffffffda RBX: 000000000000000c RCX: 0000000080000040
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000292 R12: 0000000000000000
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
>  </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:__get_vm_area_node+0x2d2/0x330 mm/vmalloc.c:3206
> Code: 03 80 3c 11 00 75 5c 48 89 43 08 e9 4b ff ff ff e8 43 a8 a4 ff 48 89 df e8 db 98 05 00 31 db e9 37 ff ff ff e8 2f a8 a4 ff 90 <0f> 0b e8 77 6b 11 00 e9 9e fe ff ff e8 6d 6b 11 00 e9 71 fe ff ff
> RSP: 0018:ffffc90006f76860 EFLAGS: 00010246
> RAX: 0000000000080000 RBX: 0000000000000200 RCX: ffffc90034405000
> RDX: 0000000000080000 RSI: ffffffff82633fb1 RDI: ffff8880244b4a00
> RBP: 000000000000000c R08: 0000000000000005 R09: 0000000000000000
> R10: 0000000000000200 R11: 0000000000000000 R12: 0000000000000022
> R13: 0000000000008080 R14: 0000000000000001 R15: 0000000000000000
> FS:  0000000000000000(0000) GS:ffff88809727d000(0063) knlGS:00000000f4f61b40
> CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
> CR2: 00000000f73c4f50 CR3: 0000000055b77000 CR4: 0000000000352ef0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 000000000000000e DR6: 00000000ffff0ff0 DR7: 0000000000000400
> ----------------
> Code disassembly (best guess):
>    0:	d2 74 05 c1          	shlb   %cl,-0x3f(%rbp,%rax,1)
>    4:	e8 0c 89 02 8b       	call   0x8b028915
>    9:	5d                   	pop    %rbp
>    a:	fc                   	cld
>    b:	31 c0                	xor    %eax,%eax
>    d:	c9                   	leave
>    e:	c3                   	ret
>    f:	90                   	nop
>   10:	90                   	nop
>   11:	90                   	nop
>   12:	90                   	nop
>   13:	90                   	nop
>   14:	90                   	nop
>   15:	90                   	nop
>   16:	90                   	nop
>   17:	90                   	nop
>   18:	90                   	nop
>   19:	90                   	nop
>   1a:	90                   	nop
>   1b:	90                   	nop
>   1c:	90                   	nop
>   1d:	90                   	nop
>   1e:	0f 1f 00             	nopl   (%rax)
>   21:	51                   	push   %rcx
>   22:	52                   	push   %rdx
>   23:	55                   	push   %rbp
>   24:	89 e5                	mov    %esp,%ebp
>   26:	0f 34                	sysenter
>   28:	cd 80                	int    $0x80
> * 2a:	5d                   	pop    %rbp <-- trapping instruction
>   2b:	5a                   	pop    %rdx
>   2c:	59                   	pop    %rcx
>   2d:	c3                   	ret
>   2e:	90                   	nop
>   2f:	2e 8d b4 26 00 00 00 	cs lea 0x0(%rsi,%riz,1),%esi
>   36:	00
>   37:	8d b4 26 00 00 00 00 	lea    0x0(%rsi,%riz,1),%esi
>   3e:	58                   	pop    %rax
>   3f:	b8                   	.byte 0xb8
> 
> 
> ---
> 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 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [syzbot] [bridge?] kernel BUG in __get_vm_area_node
  2026-05-12  8:47 ` Ido Schimmel
@ 2026-05-12  9:26   ` Uladzislau Rezki
  2026-05-12 13:17     ` Uladzislau Rezki
  0 siblings, 1 reply; 4+ messages in thread
From: Uladzislau Rezki @ 2026-05-12  9:26 UTC (permalink / raw)
  To: Ido Schimmel
  Cc: syzbot, urezki, bridge, davem, edumazet, horms, kuba,
	linux-kernel, netdev, pabeni, razor, syzkaller-bugs, fw

On Tue, May 12, 2026 at 11:47:54AM +0300, Ido Schimmel wrote:
> On Sat, May 09, 2026 at 12:35:24PM -0700, syzbot wrote:
> > Hello,
> > 
> > syzbot found the following issue on:
> > 
> > HEAD commit:    9207d47f966b Merge tag 'for-linus' of git://git.kernel.org..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=17e44d06580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=d0f0911eedbc130a
> > dashboard link: https://syzkaller.appspot.com/bug?extid=8b12fc6e0fb139765b58
> > compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> > userspace arch: i386
> > 
> > Unfortunately, I don't have any reproducer for this issue yet.
> > 
> > Downloadable assets:
> > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-9207d47f.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/6c5e883f31aa/vmlinux-9207d47f.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/19f3e863ae5c/bzImage-9207d47f.xz
> > 
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+8b12fc6e0fb139765b58@syzkaller.appspotmail.com
> > 
> > ------------[ cut here ]------------
> > kernel BUG at mm/vmalloc.c:3206!
> 
> It seems that this bug was fixed by commit 30c19366636f ("mm: fix BUG
> splat with kvmalloc + GFP_ATOMIC"), but then commit c6307674ed82 ("mm:
> kvmalloc: add non-blocking support for vmalloc") re-introduced it.
> 
> Uladzislau, can you please look into it?
> 
> Note that the bridge is calling rhashtable_lookup_insert_fast() with BH
> disabled.
> 
Yep, since vmalloc can be called with ATOMIC/NOWAIT flags now. I am
checking this. Probably we can just remove below check:

<snip>
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 676851d5cfe7..3d338e4bcbf7 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3209,7 +3209,6 @@ struct vm_struct *__get_vm_area_node(unsigned long size,
        struct vm_struct *area;
        unsigned long requested_size = size;

-       BUG_ON(in_interrupt());
        size = ALIGN(size, 1ul << shift);
        if (unlikely(!size))
                return NULL;
<snip>

We have already the check:

	gfp_mask = gfp_mask & GFP_RECLAIM_MASK;
	allow_block = gfpflags_allow_blocking(gfp_mask);
	might_sleep_if(allow_block);

in alloc_vmap_area().

--
Uladzislau Rezki

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [syzbot] [bridge?] kernel BUG in __get_vm_area_node
  2026-05-12  9:26   ` Uladzislau Rezki
@ 2026-05-12 13:17     ` Uladzislau Rezki
  0 siblings, 0 replies; 4+ messages in thread
From: Uladzislau Rezki @ 2026-05-12 13:17 UTC (permalink / raw)
  To: Ido Schimmel
  Cc: Ido Schimmel, syzbot, bridge, davem, edumazet, horms, kuba,
	linux-kernel, netdev, pabeni, razor, syzkaller-bugs, fw

On Tue, May 12, 2026 at 11:26:06AM +0200, Uladzislau Rezki wrote:
> On Tue, May 12, 2026 at 11:47:54AM +0300, Ido Schimmel wrote:
> > On Sat, May 09, 2026 at 12:35:24PM -0700, syzbot wrote:
> > > Hello,
> > > 
> > > syzbot found the following issue on:
> > > 
> > > HEAD commit:    9207d47f966b Merge tag 'for-linus' of git://git.kernel.org..
> > > git tree:       upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=17e44d06580000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=d0f0911eedbc130a
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=8b12fc6e0fb139765b58
> > > compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> > > userspace arch: i386
> > > 
> > > Unfortunately, I don't have any reproducer for this issue yet.
> > > 
> > > Downloadable assets:
> > > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-9207d47f.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/6c5e883f31aa/vmlinux-9207d47f.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/19f3e863ae5c/bzImage-9207d47f.xz
> > > 
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+8b12fc6e0fb139765b58@syzkaller.appspotmail.com
> > > 
> > > ------------[ cut here ]------------
> > > kernel BUG at mm/vmalloc.c:3206!
> > 
> > It seems that this bug was fixed by commit 30c19366636f ("mm: fix BUG
> > splat with kvmalloc + GFP_ATOMIC"), but then commit c6307674ed82 ("mm:
> > kvmalloc: add non-blocking support for vmalloc") re-introduced it.
> > 
> > Uladzislau, can you please look into it?
> > 
> > Note that the bridge is calling rhashtable_lookup_insert_fast() with BH
> > disabled.
> > 
> Yep, since vmalloc can be called with ATOMIC/NOWAIT flags now. I am
> checking this. Probably we can just remove below check:
> 
> <snip>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 676851d5cfe7..3d338e4bcbf7 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3209,7 +3209,6 @@ struct vm_struct *__get_vm_area_node(unsigned long size,
>         struct vm_struct *area;
>         unsigned long requested_size = size;
> 
> -       BUG_ON(in_interrupt());
>         size = ALIGN(size, 1ul << shift);
>         if (unlikely(!size))
>                 return NULL;
> <snip>
> 
> We have already the check:
> 
> 	gfp_mask = gfp_mask & GFP_RECLAIM_MASK;
> 	allow_block = gfpflags_allow_blocking(gfp_mask);
> 	might_sleep_if(allow_block);
> 
> in alloc_vmap_area().
> 
Actually since we are not allowed to call vmalloc from NMI nor IRQ
context. We should keep the check. But in a slightly different form:

<snip>
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 676851d5cfe7..273bbe49eaef 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3209,7 +3209,7 @@ struct vm_struct *__get_vm_area_node(unsigned long size,
 	struct vm_struct *area;
 	unsigned long requested_size = size;
 
-	BUG_ON(in_interrupt());
+	BUG_ON(in_nmi() || in_hardirq());
 	size = ALIGN(size, 1ul << shift);
 	if (unlikely(!size))
 		return NULL;
<snip>

if any context disables BH, i.e. local_bh_disable() it does not mean we
are in IRQ context. Furthermore the documentation about in_interrupt()
says:

<snip>
/*
 * The following macros are deprecated and should not be used in new code:
 * in_softirq()   - We have BH disabled, or are processing softirqs
 * in_interrupt() - We're in NMI,IRQ,SoftIRQ context or have BH disabled
 */
#define in_softirq()		(softirq_count())
#define in_interrupt()		(irq_count())
<snip>

those are should not be used.

--
Uladzislau Rezki

^ permalink raw reply related	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-05-12 13:17 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-09 19:35 [syzbot] [bridge?] kernel BUG in __get_vm_area_node syzbot
2026-05-12  8:47 ` Ido Schimmel
2026-05-12  9:26   ` Uladzislau Rezki
2026-05-12 13:17     ` Uladzislau Rezki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox