[syzbot] [bpf?] general protection fault in bpf_get_local_storage (2)

[syzbot] [bpf?] general protection fault in bpf_get_local_storage (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    3f0e9c8cefa9 Merge tag 'block-6.19-20251226' of git://git...
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11765022580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=513255d80ab78f2b
dashboard link: https://syzkaller.appspot.com/bug?extid=4fe468a3f7fac86ea2c9
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1071089a580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11dd1bb4580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-3f0e9c8c.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/275bd6cb3fb6/vmlinux-3f0e9c8c.xz
kernel image: https://storage.googleapis.com/syzbot-assets/d5311a1a21c3/bzImage-3f0e9c8c.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+4fe468a3f7fac86ea2c9@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: 0 UID: 0 PID: 9 Comm: kworker/0:0 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
Workqueue: rcu_gp process_srcu
RIP: 0010:____bpf_get_local_storage kernel/bpf/cgroup.c:1774 [inline]
RIP: 0010:bpf_get_local_storage+0xbd/0x180 kernel/bpf/cgroup.c:1756
Code: e0 49 83 c6 08 4c 89 f0 48 c1 e8 03 42 80 3c 38 00 74 08 4c 89 f7 e8 a2 83 39 00 4d 8b 36 83 fb 15 75 5c 4c 89 f0 48 c1 e8 03 <42> 80 3c 38 00 74 08 4c 89 f7 e8 84 83 39 00 49 8b 1e e8 ec 7e 6c
RSP: 0018:ffffc900000072d8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000015 RCX: 0000000000000100
RDX: ffff88801bef4980 RSI: 0000000000000015 RDI: 0000000000000015
RBP: ffffc90000007310 R08: 0000000000000003 R09: 0000000000000000
R10: ffffc90000007380 R11: ffffffffa0203ce4 R12: 0000000000000001
R13: ffff88801248d640 R14: 0000000000000000 R15: dffffc0000000000
FS:  0000000000000000(0000) GS:ffff88808d416000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000001c40 CR3: 000000003701b000 CR4: 0000000000352ef0
Call Trace:
 <IRQ>
 bpf_prog_e63b106389d7305a+0x2e/0x45
 bpf_dispatcher_nop_func include/linux/bpf.h:1378 [inline]
 __bpf_prog_run include/linux/filter.h:723 [inline]
 bpf_prog_run include/linux/filter.h:730 [inline]
 __bpf_prog_run_save_cb+0x127/0x370 include/linux/filter.h:980
 bpf_prog_run_array_cg kernel/bpf/cgroup.c:81 [inline]
 __cgroup_bpf_run_filter_skb+0x9e0/0xf40 kernel/bpf/cgroup.c:1612
 sk_filter_trim_cap+0xd42/0xf50 net/core/filter.c:150
 tcp_filter net/ipv4/tcp_ipv4.c:2117 [inline]
 tcp_v4_rcv+0x1f90/0x2f20 net/ipv4/tcp_ipv4.c:2304
 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:207
 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241
 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318
 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318
 __netif_receive_skb_one_core net/core/dev.c:6137 [inline]
 __netif_receive_skb+0x143/0x380 net/core/dev.c:6250
 process_backlog+0x54f/0x1340 net/core/dev.c:6602
 __napi_poll+0xae/0x320 net/core/dev.c:7666
 napi_poll net/core/dev.c:7729 [inline]
 net_rx_action+0x64a/0xe00 net/core/dev.c:7881
 handle_softirqs+0x22b/0x7c0 kernel/softirq.c:622
 __do_softirq kernel/softirq.c:656 [inline]
 invoke_softirq kernel/softirq.c:496 [inline]
 __irq_exit_rcu+0x60/0x150 kernel/softirq.c:723
 irq_exit_rcu+0x9/0x30 kernel/softirq.c:739
 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]
 sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1056
 </IRQ>
 <TASK>
 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:delay_loop+0x20/0x30 arch/x86/lib/delay.c:44
Code: 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 89 f8 48 85 c0 74 19 eb 02 66 90 eb 0e 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 <48> ff c8 75 fb 48 ff c8 c3 cc cc cc cc cc 66 90 90 90 90 90 90 90
RSP: 0018:ffffc900001b78d0 EFLAGS: 00000216
RAX: 00000000000022ff RBX: 0000000000000001 RCX: 0000000008583a9c
RDX: 00000000000036b0 RSI: 0000000000000008 RDI: 00000000000036b1
RBP: 0000000000000001 R08: ffff88801fc42b47 R09: 1ffff11003f88568
R10: dffffc0000000000 R11: ffffffff8b5a31d0 R12: 0000000000000001
R13: 0000000000004fb8 R14: ffff88801fc42b60 R15: dffffc0000000000
 udelay include/asm-generic/delay.h:64 [inline]
 try_check_zero+0x412/0x470 kernel/rcu/srcutree.c:1182
 srcu_advance_state kernel/rcu/srcutree.c:1886 [inline]
 process_srcu+0x2d3/0x1220 kernel/rcu/srcutree.c:1995
 process_one_work kernel/workqueue.c:3257 [inline]
 process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340
 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421
 kthread+0x711/0x8a0 kernel/kthread.c:463
 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:____bpf_get_local_storage kernel/bpf/cgroup.c:1774 [inline]
RIP: 0010:bpf_get_local_storage+0xbd/0x180 kernel/bpf/cgroup.c:1756
Code: e0 49 83 c6 08 4c 89 f0 48 c1 e8 03 42 80 3c 38 00 74 08 4c 89 f7 e8 a2 83 39 00 4d 8b 36 83 fb 15 75 5c 4c 89 f0 48 c1 e8 03 <42> 80 3c 38 00 74 08 4c 89 f7 e8 84 83 39 00 49 8b 1e e8 ec 7e 6c
RSP: 0018:ffffc900000072d8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000015 RCX: 0000000000000100
RDX: ffff88801bef4980 RSI: 0000000000000015 RDI: 0000000000000015
RBP: ffffc90000007310 R08: 0000000000000003 R09: 0000000000000000
R10: ffffc90000007380 R11: ffffffffa0203ce4 R12: 0000000000000001
R13: ffff88801248d640 R14: 0000000000000000 R15: dffffc0000000000
FS:  0000000000000000(0000) GS:ffff88808d416000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000001c40 CR3: 000000003701b000 CR4: 0000000000352ef0
----------------
Code disassembly (best guess):
   0:	e0 49                	loopne 0x4b
   2:	83 c6 08             	add    $0x8,%esi
   5:	4c 89 f0             	mov    %r14,%rax
   8:	48 c1 e8 03          	shr    $0x3,%rax
   c:	42 80 3c 38 00       	cmpb   $0x0,(%rax,%r15,1)
  11:	74 08                	je     0x1b
  13:	4c 89 f7             	mov    %r14,%rdi
  16:	e8 a2 83 39 00       	call   0x3983bd
  1b:	4d 8b 36             	mov    (%r14),%r14
  1e:	83 fb 15             	cmp    $0x15,%ebx
  21:	75 5c                	jne    0x7f
  23:	4c 89 f0             	mov    %r14,%rax
  26:	48 c1 e8 03          	shr    $0x3,%rax
* 2a:	42 80 3c 38 00       	cmpb   $0x0,(%rax,%r15,1) <-- trapping instruction
  2f:	74 08                	je     0x39
  31:	4c 89 f7             	mov    %r14,%rdi
  34:	e8 84 83 39 00       	call   0x3983bd
  39:	49 8b 1e             	mov    (%r14),%rbx
  3c:	e8                   	.byte 0xe8
  3d:	ec                   	in     (%dx),%al
  3e:	7e 6c                	jle    0xac


---
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] [bpf?] general protection fault in bpf_get_local_storage (2)

[Liang Jie]

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

diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index 69988af44b37..2bc27ece5cc5 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -1768,6 +1768,9 @@ BPF_CALL_2(bpf_get_local_storage, struct bpf_map *, map, u64, flags)
        ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx);
        storage = ctx->prog_item->cgroup_storage[stype];
 
+       if (unlikely(!storage))
+               return (unsigned long)NULL;
+
        if (stype == BPF_CGROUP_STORAGE_SHARED)
                ptr = &READ_ONCE(storage->buf)->data[0];

Re: [syzbot] [bpf?] general protection fault in bpf_get_local_storage (2)

[syzbot]

Hello,

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

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

Tested on:

commit:         3f0e9c8c Merge tag 'block-6.19-20251226' of git://git...
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=13bb9792580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=513255d80ab78f2b
dashboard link: https://syzkaller.appspot.com/bug?extid=4fe468a3f7fac86ea2c9
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=10fca422580000

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

Re: [syzbot] [bpf?] general protection fault in bpf_get_local_storage (2)

[Amery Hung]

On Tue, Dec 30, 2025 at 7:21 PM Liang Jie <buaajxlj@163.com> wrote:
>
> #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 3f0e9c8cefa9
>
> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index 69988af44b37..2bc27ece5cc5 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c
> @@ -1768,6 +1768,9 @@ BPF_CALL_2(bpf_get_local_storage, struct bpf_map *, map, u64, flags)
>         ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx);
>         storage = ctx->prog_item->cgroup_storage[stype];
>
> +       if (unlikely(!storage))
> +               return (unsigned long)NULL;
> +
>         if (stype == BPF_CGROUP_STORAGE_SHARED)
>                 ptr = &READ_ONCE(storage->buf)->data[0];
>
>

Hi Liang,

I don't think we can do this here due to backward compatibility. The
return type of the helper is RET_PTR_TO_MAP_VALUE. Your proposed fix
would require adding a PTR_MAYBE_NULL and existing BPF programs would
no longer pass the verifier.

Did you look into why the storage pointer is NULL in the first place?

BTW, there is also another similar report and a work-in-progress fix
[1]. Do you think this is a separate issue from that?

Thanks,
Amery

[1] https://lore.kernel.org/bpf/20251203195050.3215728-1-ameryhung@gmail.com/

Re: [syzbot] [bpf?] general protection fault in bpf_get_local_storage (2)

[Liang Jie]

On Tue, 30 Dec 2025 22:18:00 -0800, Amery Hung <ameryhung@gmail.com> wrote:
> >
> > #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 3f0e9c8cefa9
> >
> > diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> > index 69988af44b37..2bc27ece5cc5 100644
> > --- a/kernel/bpf/cgroup.c
> > +++ b/kernel/bpf/cgroup.c
> > @@ -1768,6 +1768,9 @@ BPF_CALL_2(bpf_get_local_storage, struct bpf_map *, map, u64, flags)
> >         ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx);
> >         storage = ctx->prog_item->cgroup_storage[stype];
> >
> > +       if (unlikely(!storage))
> > +               return (unsigned long)NULL;
> > +
> >         if (stype == BPF_CGROUP_STORAGE_SHARED)
> >                 ptr = &READ_ONCE(storage->buf)->data[0];
> >
> >
> 
> Hi Liang,
> 
> I don't think we can do this here due to backward compatibility. The
> return type of the helper is RET_PTR_TO_MAP_VALUE. Your proposed fix
> would require adding a PTR_MAYBE_NULL and existing BPF programs would
> no longer pass the verifier.
> 
> Did you look into why the storage pointer is NULL in the first place?
> 
> BTW, there is also another similar report and a work-in-progress fix
> [1]. Do you think this is a separate issue from that?

Hi Amery,

Thanks for pointing this out.

Sorry, I initially missed your earlier WIP fix. Looking at it now, this
does seem to be addressing the same class of issues where
bpf_get_local_storage() can observe a NULL storage pointer.

I'm interested in this area and will take a closer look to see whether
your patch also covers the syzbot report.

Thanks,
Liang