[syzbot] [bpf?] KASAN: slab-out-of-bounds Read in strnchr

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 22cc16c04b78 riscv, bpf: Fix incorrect usage of BPF_TRAMP_..
git tree: bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=1391f792580000
kernel config: https://syzkaller.appspot.com/x/.config?x=a94030c847137a18
dashboard link: https://syzkaller.appspot.com/bug?extid=2c29addf92581b410079
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=10c82e22580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16de569a580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/43a53493cb5f/disk-22cc16c0.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/9726fb9e1980/vmlinux-22cc16c0.xz
kernel image: https://storage.googleapis.com/syzbot-assets/efd2bc050ab6/bzImage-22cc16c0.xz

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

==================================================================
BUG: KASAN: slab-out-of-bounds in strnchr+0x5e/0x80 lib/string.c:405
Read of size 1 at addr ffff888029e093b0 by task ksoftirqd/1/23

CPU: 1 UID: 0 PID: 23 Comm: ksoftirqd/1 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xca/0x240 mm/kasan/report.c:482
kasan_report+0x118/0x150 mm/kasan/report.c:595
strnchr+0x5e/0x80 lib/string.c:405
bpf_bprintf_prepare+0x167/0x13d0 kernel/bpf/helpers.c:829
____bpf_snprintf kernel/bpf/helpers.c:1065 [inline]
bpf_snprintf+0xd3/0x1b0 kernel/bpf/helpers.c:1049
bpf_prog_c2925c0a7ac12d80+0x58/0x60
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_trace_run kernel/trace/bpf_trace.c:2075 [inline]
bpf_trace_run1+0x27f/0x4c0 kernel/trace/bpf_trace.c:2115
__bpf_trace_rcu_utilization+0xa1/0xf0 include/trace/events/rcu.h:27
__do_trace_rcu_utilization include/trace/events/rcu.h:27 [inline]
trace_rcu_utilization+0x191/0x1c0 include/trace/events/rcu.h:27
rcu_core+0x13fe/0x1870 kernel/rcu/tree.c:2865
handle_softirqs+0x27d/0x850 kernel/softirq.c:622
run_ksoftirqd+0x9b/0x100 kernel/softirq.c:1063
smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160
kthread+0x711/0x8a0 kernel/kthread.c:463
ret_from_fork+0x599/0xb30 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
</TASK>

Allocated by task 6022:
kasan_save_stack mm/kasan/common.c:56 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:77
poison_kmalloc_redzone mm/kasan/common.c:397 [inline]
__kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:414
kasan_kmalloc include/linux/kasan.h:262 [inline]
__do_kmalloc_node mm/slub.c:5657 [inline]
__kmalloc_node_noprof+0x57a/0x820 mm/slub.c:5663
kmalloc_node_noprof include/linux/slab.h:987 [inline]
__bpf_map_area_alloc kernel/bpf/syscall.c:395 [inline]
bpf_map_area_alloc+0x64/0x180 kernel/bpf/syscall.c:408
insn_array_alloc+0x52/0x140 kernel/bpf/bpf_insn_array.c:49
map_create+0xafd/0x16a0 kernel/bpf/syscall.c:1514
__sys_bpf+0x5f0/0x860 kernel/bpf/syscall.c:6146
__do_sys_bpf kernel/bpf/syscall.c:6274 [inline]
__se_sys_bpf kernel/bpf/syscall.c:6272 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff888029e09000
which belongs to the cache kmalloc-cg-1k of size 1024
The buggy address is located 0 bytes to the right of
allocated 944-byte region [ffff888029e09000, ffff888029e093b0)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x29e08
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
memcg:ffff888072141701
flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000040 ffff88813ffb0280 dead000000000100 dead000000000122
raw: 0000000000000000 0000000080100010 00000000f5000000 ffff888072141701
head: 00fff00000000040 ffff88813ffb0280 dead000000000100 dead000000000122
head: 0000000000000000 0000000080100010 00000000f5000000 ffff888072141701
head: 00fff00000000003 ffffea0000a78201 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5709, tgid 5709 (dhcpcd-run-hook), ts 83835394493, free_ts 83796353079
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x234/0x290 mm/page_alloc.c:1846
prep_new_page mm/page_alloc.c:1854 [inline]
get_page_from_freelist+0x2365/0x2440 mm/page_alloc.c:3915
__alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5210
alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2486
alloc_slab_page mm/slub.c:3075 [inline]
allocate_slab+0x86/0x3b0 mm/slub.c:3248
new_slab mm/slub.c:3302 [inline]
___slab_alloc+0xf2b/0x1960 mm/slub.c:4656
__slab_alloc+0x65/0x100 mm/slub.c:4779
__slab_alloc_node mm/slub.c:4855 [inline]
slab_alloc_node mm/slub.c:5251 [inline]
__do_kmalloc_node mm/slub.c:5656 [inline]
__kmalloc_noprof+0x47d/0x800 mm/slub.c:5669
kmalloc_noprof include/linux/slab.h:961 [inline]
kmalloc_array_noprof include/linux/slab.h:1003 [inline]
alloc_pipe_info+0x1fd/0x4d0 fs/pipe.c:817
get_pipe_inode fs/pipe.c:896 [inline]
create_pipe_files+0x8a/0x7e0 fs/pipe.c:928
__do_pipe_flags+0x46/0x1f0 fs/pipe.c:990
do_pipe2+0x9c/0x170 fs/pipe.c:1038
__do_sys_pipe2 fs/pipe.c:1056 [inline]
__se_sys_pipe2 fs/pipe.c:1054 [inline]
__x64_sys_pipe2+0x5a/0x70 fs/pipe.c:1054
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 5712 tgid 5712 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
free_pages_prepare mm/page_alloc.c:1395 [inline]
__free_frozen_pages+0xbc8/0xd30 mm/page_alloc.c:2943
__slab_free+0x21b/0x2a0 mm/slub.c:6004
qlink_free mm/kasan/quarantine.c:163 [inline]
qlist_free_all+0x97/0x100 mm/kasan/quarantine.c:179
kasan_quarantine_reduce+0x148/0x160 mm/kasan/quarantine.c:286
__kasan_slab_alloc+0x22/0x80 mm/kasan/common.c:349
kasan_slab_alloc include/linux/kasan.h:252 [inline]
slab_post_alloc_hook mm/slub.c:4953 [inline]
slab_alloc_node mm/slub.c:5263 [inline]
kmem_cache_alloc_noprof+0x37d/0x710 mm/slub.c:5270
vm_area_alloc+0x24/0x140 mm/vma_init.c:32
__mmap_new_vma mm/vma.c:2469 [inline]
__mmap_region mm/vma.c:2708 [inline]
mmap_region+0xdea/0x1d10 mm/vma.c:2786
do_mmap+0xc45/0x10d0 mm/mmap.c:558
vm_mmap_pgoff+0x2a6/0x4d0 mm/util.c:581
ksys_mmap_pgoff+0x51f/0x760 mm/mmap.c:604
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

Memory state around the buggy address:
ffff888029e09280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff888029e09300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff888029e09380: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
^
ffff888029e09400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888029e09480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================


---
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 syzk...@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

[syzbot]

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

***

Subject: [PATCH] bpf: Fix double offset in check_reg_const_str()
Author: karti...@gmail.com

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

map_direct_value_addr() returns the address already offset by map_off,
but check_reg_const_str() adds map_off again when calling strnchr().
This causes the null-termination check to read from the wrong address,
potentially past the end of the map value buffer.

This triggers a KASAN slab-out-of-bounds in strnchr() when a BPF program
passes a PTR_TO_MAP_VALUE to a helper expecting ARG_PTR_TO_CONST_STR,
as the verifier fails to properly validate the string is null-terminated
within bounds.

Remove the redundant offset addition since map_addr already points to
the correct location.

Reported-by: syzbot+2c29ad...@syzkaller.appspotmail.com
Fixes: 0b51940729150 ("bpf: Factor out helper check_reg_const_str()")
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---
kernel/bpf/verifier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index f0ca69f888fa..b1cb501fb577 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -9638,7 +9638,7 @@ static int check_reg_const_str(struct bpf_verifier_env *env,
}

str_ptr = (char *)(long)(map_addr);
- if (!strnchr(str_ptr + map_off, map->value_size - map_off, 0)) {
+ if (!strnchr(str_ptr, map->value_size - map_off, 0)) {
verbose(env, "string is not zero-terminated\n");
return -EINVAL;
}
--
2.43.0

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: slab-out-of-bounds Read in strnchr

==================================================================
BUG: KASAN: slab-out-of-bounds in strnchr+0x5e/0x80 lib/string.c:405

Read of size 1 at addr ffff888029166bb0 by task syz.0.17/6458

CPU: 0 UID: 0 PID: 6458 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xca/0x240 mm/kasan/report.c:482
kasan_report+0x118/0x150 mm/kasan/report.c:595
strnchr+0x5e/0x80 lib/string.c:405
bpf_bprintf_prepare+0x167/0x13d0 kernel/bpf/helpers.c:829
____bpf_snprintf kernel/bpf/helpers.c:1065 [inline]
bpf_snprintf+0xd3/0x1b0 kernel/bpf/helpers.c:1049
bpf_prog_c2925c0a7ac12d80+0x58/0x60
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_trace_run kernel/trace/bpf_trace.c:2075 [inline]
bpf_trace_run1+0x27f/0x4c0 kernel/trace/bpf_trace.c:2115
__bpf_trace_rcu_utilization+0xa1/0xf0 include/trace/events/rcu.h:27
__do_trace_rcu_utilization include/trace/events/rcu.h:27 [inline]
trace_rcu_utilization+0x191/0x1c0 include/trace/events/rcu.h:27

rcu_note_context_switch+0xc9/0x1120 kernel/rcu/tree_plugin.h:330
__schedule+0x346/0x5000 kernel/sched/core.c:6748
preempt_schedule_common+0x83/0xd0 kernel/sched/core.c:7047
preempt_schedule+0xae/0xc0 kernel/sched/core.c:7071
preempt_schedule_thunk+0x16/0x30 arch/x86/entry/thunk.S:12
class_preempt_destructor include/linux/preempt.h:468 [inline]
try_to_wake_up+0x82b/0x12b0 kernel/sched/core.c:4225
wake_up_process kernel/sched/core.c:4349 [inline]
wake_up_q+0x85/0xd0 kernel/sched/core.c:1087
futex_wake+0x4a0/0x560 kernel/futex/waitwake.c:198
do_futex+0x395/0x420 kernel/futex/syscalls.c:135
__do_sys_futex kernel/futex/syscalls.c:207 [inline]
__se_sys_futex+0x36f/0x400 kernel/futex/syscalls.c:188

do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

RIP: 0033:0x7f540bd8f749
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:00007f540cc950e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: ffffffffffffffda RBX: 00007f540bfe5fa8 RCX: 00007f540bd8f749
RDX: 00000000000f4240 RSI: 0000000000000081 RDI: 00007f540bfe5fac
RBP: 00007f540bfe5fa0 R08: 3fffffffffffffff R09: 0000000000000000
R10: 0000000000000005 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f540bfe6038 R14: 00007ffe4f3ebe10 R15: 00007ffe4f3ebef8
</TASK>

Allocated by task 6458:

kasan_save_stack mm/kasan/common.c:56 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:77
poison_kmalloc_redzone mm/kasan/common.c:397 [inline]
__kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:414
kasan_kmalloc include/linux/kasan.h:262 [inline]
__do_kmalloc_node mm/slub.c:5657 [inline]
__kmalloc_node_noprof+0x57a/0x820 mm/slub.c:5663
kmalloc_node_noprof include/linux/slab.h:987 [inline]
__bpf_map_area_alloc kernel/bpf/syscall.c:395 [inline]
bpf_map_area_alloc+0x64/0x180 kernel/bpf/syscall.c:408
insn_array_alloc+0x52/0x140 kernel/bpf/bpf_insn_array.c:49
map_create+0xafd/0x16a0 kernel/bpf/syscall.c:1514
__sys_bpf+0x5f0/0x860 kernel/bpf/syscall.c:6146
__do_sys_bpf kernel/bpf/syscall.c:6274 [inline]
__se_sys_bpf kernel/bpf/syscall.c:6272 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff888029166800

which belongs to the cache kmalloc-cg-1k of size 1024
The buggy address is located 0 bytes to the right of

allocated 944-byte region [ffff888029166800, ffff888029166bb0)

The buggy address belongs to the physical page:

page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x29160

head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0

memcg:ffff8880287ecb01

flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)

raw: 00fff00000000040 ffff88813ffb0280 ffffea0000c50e00 dead000000000002
raw: 0000000000000000 0000000080100010 00000000f5000000 ffff8880287ecb01
head: 00fff00000000040 ffff88813ffb0280 ffffea0000c50e00 dead000000000002
head: 0000000000000000 0000000080100010 00000000f5000000 ffff8880287ecb01
head: 00fff00000000003 ffffea0000a45801 00000000ffffffff 00000000ffffffff

head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated

page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5651, tgid 5651 (dhcpcd-run-hook), ts 58371581863, free_ts 57441834104

page last free pid 5493 tgid 5493 stack trace:

reset_page_owner include/linux/page_owner.h:25 [inline]
free_pages_prepare mm/page_alloc.c:1395 [inline]
__free_frozen_pages+0xbc8/0xd30 mm/page_alloc.c:2943

discard_slab mm/slub.c:3346 [inline]
__put_partials+0x146/0x170 mm/slub.c:3886
put_cpu_partial+0x1f2/0x2d0 mm/slub.c:3961
__slab_free+0x288/0x2a0 mm/slub.c:5952

qlink_free mm/kasan/quarantine.c:163 [inline]
qlist_free_all+0x97/0x100 mm/kasan/quarantine.c:179
kasan_quarantine_reduce+0x148/0x160 mm/kasan/quarantine.c:286
__kasan_slab_alloc+0x22/0x80 mm/kasan/common.c:349
kasan_slab_alloc include/linux/kasan.h:252 [inline]
slab_post_alloc_hook mm/slub.c:4953 [inline]
slab_alloc_node mm/slub.c:5263 [inline]

kmem_cache_alloc_node_noprof+0x43c/0x720 mm/slub.c:5315
__alloc_skb+0x255/0x430 net/core/skbuff.c:679
alloc_skb include/linux/skbuff.h:1383 [inline]
alloc_skb_with_frags+0xca/0x890 net/core/skbuff.c:6712
sock_alloc_send_pskb+0x84d/0x980 net/core/sock.c:2995
unix_dgram_sendmsg+0x454/0x1840 net/unix/af_unix.c:2130
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg+0x21c/0x270 net/socket.c:742
sock_write_iter+0x279/0x360 net/socket.c:1195
new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x5c9/0xb30 fs/read_write.c:686
ksys_write+0x145/0x250 fs/read_write.c:738

Memory state around the buggy address:

ffff888029166a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff888029166b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff888029166b80: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
^
ffff888029166c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888029166c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================


Tested on:

commit: 22cc16c0 riscv, bpf: Fix incorrect usage of BPF_TRAMP_..
git tree: bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=156d7efc580000

kernel config: https://syzkaller.appspot.com/x/.config?x=a94030c847137a18
dashboard link: https://syzkaller.appspot.com/bug?extid=2c29addf92581b410079
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=11f90e9a580000

[syzbot]

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

***

Subject: [PATCH] bpf: Fix double offset in insn_array_map_direct_value_addr()

Author: karti...@gmail.com

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

insn_array_map_direct_value_addr() adds the offset to the returned
address, but callers of map_direct_value_addr() expect the base address
and add the offset themselves. This is inconsistent with other
implementations like array_map_direct_value_addr() and
arena_map_direct_value_addr() which return only the base address.

This causes a double offset when check_reg_const_str() validates
ARG_PTR_TO_CONST_STR arguments, leading to an out-of-bounds read
in strnchr() when bpf_snprintf() is called with a format string
from an insn_array map.

Remove the offset addition to match the expected behavior.

Reported-by: syzbot+2c29ad...@syzkaller.appspotmail.com

Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---

kernel/bpf/bpf_insn_array.c | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/bpf/bpf_insn_array.c b/kernel/bpf/bpf_insn_array.c
index c96630cb75bf..37b43102953e 100644
--- a/kernel/bpf/bpf_insn_array.c
+++ b/kernel/bpf/bpf_insn_array.c
@@ -126,7 +126,7 @@ static int insn_array_map_direct_value_addr(const struct bpf_map *map, u64 *imm,
return -EINVAL;

/* from BPF's point of view, this map is a jump table */
- *imm = (unsigned long)insn_array->ips + off;
+ *imm = (unsigned long)insn_array->ips;

return 0;
}
--
2.43.0

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: slab-out-of-bounds Read in strnchr

==================================================================
BUG: KASAN: slab-out-of-bounds in strnchr+0x5e/0x80 lib/string.c:405

Read of size 1 at addr ffff8880796d9bb0 by task syz.0.17/6447

CPU: 1 UID: 0 PID: 6447 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xca/0x240 mm/kasan/report.c:482
kasan_report+0x118/0x150 mm/kasan/report.c:595
strnchr+0x5e/0x80 lib/string.c:405
bpf_bprintf_prepare+0x167/0x13d0 kernel/bpf/helpers.c:829
____bpf_snprintf kernel/bpf/helpers.c:1065 [inline]
bpf_snprintf+0xd3/0x1b0 kernel/bpf/helpers.c:1049
bpf_prog_c2925c0a7ac12d80+0x58/0x60
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_trace_run kernel/trace/bpf_trace.c:2075 [inline]
bpf_trace_run1+0x27f/0x4c0 kernel/trace/bpf_trace.c:2115
__bpf_trace_rcu_utilization+0xa1/0xf0 include/trace/events/rcu.h:27
__do_trace_rcu_utilization include/trace/events/rcu.h:27 [inline]
trace_rcu_utilization+0x191/0x1c0 include/trace/events/rcu.h:27
rcu_note_context_switch+0xc9/0x1120 kernel/rcu/tree_plugin.h:330
__schedule+0x346/0x5000 kernel/sched/core.c:6748

__schedule_loop kernel/sched/core.c:6945 [inline]
schedule+0x165/0x360 kernel/sched/core.c:6960
futex_do_wait kernel/futex/waitwake.c:358 [inline]
__futex_wait+0x1c3/0x3d0 kernel/futex/waitwake.c:687
futex_wait+0x104/0x360 kernel/futex/waitwake.c:715
do_futex+0x333/0x420 kernel/futex/syscalls.c:130

__do_sys_futex kernel/futex/syscalls.c:207 [inline]
__se_sys_futex+0x36f/0x400 kernel/futex/syscalls.c:188
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

RIP: 0033:0x7fe67538f749

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:00007fe6762900e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: ffffffffffffffda RBX: 00007fe6755e5fa8 RCX: 00007fe67538f749
RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fe6755e5fa8
RBP: 00007fe6755e5fa0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fe6755e6038 R14: 00007ffdb1d360a0 R15: 00007ffdb1d36188
</TASK>

Allocated by task 6447:

kasan_save_stack mm/kasan/common.c:56 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:77
poison_kmalloc_redzone mm/kasan/common.c:397 [inline]
__kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:414
kasan_kmalloc include/linux/kasan.h:262 [inline]
__do_kmalloc_node mm/slub.c:5657 [inline]
__kmalloc_node_noprof+0x57a/0x820 mm/slub.c:5663
kmalloc_node_noprof include/linux/slab.h:987 [inline]
__bpf_map_area_alloc kernel/bpf/syscall.c:395 [inline]
bpf_map_area_alloc+0x64/0x180 kernel/bpf/syscall.c:408
insn_array_alloc+0x52/0x140 kernel/bpf/bpf_insn_array.c:49
map_create+0xafd/0x16a0 kernel/bpf/syscall.c:1514
__sys_bpf+0x5f0/0x860 kernel/bpf/syscall.c:6146
__do_sys_bpf kernel/bpf/syscall.c:6274 [inline]
__se_sys_bpf kernel/bpf/syscall.c:6272 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff8880796d9800

which belongs to the cache kmalloc-cg-1k of size 1024
The buggy address is located 0 bytes to the right of

allocated 944-byte region [ffff8880796d9800, ffff8880796d9bb0)

The buggy address belongs to the physical page:

page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x796d8

head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0

memcg:ffff8880783cfa01

flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)

raw: 00fff00000000040 ffff88813ffb0280 dead000000000122 0000000000000000
raw: 0000000000000000 0000000080100010 00000000f5000000 ffff8880783cfa01
head: 00fff00000000040 ffff88813ffb0280 dead000000000122 0000000000000000
head: 0000000000000000 0000000080100010 00000000f5000000 ffff8880783cfa01
head: 00fff00000000003 ffffea0001e5b601 00000000ffffffff 00000000ffffffff

head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated

page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 6341, tgid 6341 (syz-executor), ts 133223797627, free_ts 133152404370

set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x234/0x290 mm/page_alloc.c:1846
prep_new_page mm/page_alloc.c:1854 [inline]
get_page_from_freelist+0x2365/0x2440 mm/page_alloc.c:3915
__alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5210
alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2486
alloc_slab_page mm/slub.c:3075 [inline]
allocate_slab+0x86/0x3b0 mm/slub.c:3248
new_slab mm/slub.c:3302 [inline]
___slab_alloc+0xf2b/0x1960 mm/slub.c:4656
__slab_alloc+0x65/0x100 mm/slub.c:4779
__slab_alloc_node mm/slub.c:4855 [inline]
slab_alloc_node mm/slub.c:5251 [inline]
__do_kmalloc_node mm/slub.c:5656 [inline]

__kvmalloc_node_noprof+0x6b6/0x920 mm/slub.c:7134
xt_alloc_table_info+0x40/0xb0 net/netfilter/x_tables.c:1193
do_replace net/ipv6/netfilter/ip6_tables.c:1143 [inline]
do_ip6t_set_ctl+0x88a/0xce0 net/ipv6/netfilter/ip6_tables.c:1644
nf_setsockopt+0x26f/0x290 net/netfilter/nf_sockopt.c:101
do_sock_setsockopt+0x17c/0x1b0 net/socket.c:2322
__sys_setsockopt net/socket.c:2347 [inline]
__do_sys_setsockopt net/socket.c:2353 [inline]
__se_sys_setsockopt net/socket.c:2350 [inline]
__x64_sys_setsockopt+0x13f/0x1b0 net/socket.c:2350

do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

page last free pid 6341 tgid 6341 stack trace:

reset_page_owner include/linux/page_owner.h:25 [inline]
free_pages_prepare mm/page_alloc.c:1395 [inline]
__free_frozen_pages+0xbc8/0xd30 mm/page_alloc.c:2943
discard_slab mm/slub.c:3346 [inline]
__put_partials+0x146/0x170 mm/slub.c:3886
put_cpu_partial+0x1f2/0x2d0 mm/slub.c:3961
__slab_free+0x288/0x2a0 mm/slub.c:5952
qlink_free mm/kasan/quarantine.c:163 [inline]
qlist_free_all+0x97/0x100 mm/kasan/quarantine.c:179
kasan_quarantine_reduce+0x148/0x160 mm/kasan/quarantine.c:286
__kasan_slab_alloc+0x22/0x80 mm/kasan/common.c:349
kasan_slab_alloc include/linux/kasan.h:252 [inline]
slab_post_alloc_hook mm/slub.c:4953 [inline]
slab_alloc_node mm/slub.c:5263 [inline]

__do_kmalloc_node mm/slub.c:5656 [inline]
__kmalloc_node_track_caller_noprof+0x526/0x820 mm/slub.c:5764
__kmemdup_nul mm/util.c:64 [inline]
kstrdup+0x42/0x100 mm/util.c:84
__kernfs_new_node+0x9c/0x880 fs/kernfs/dir.c:633
kernfs_new_node+0x102/0x210 fs/kernfs/dir.c:716
kernfs_create_link+0xa7/0x200 fs/kernfs/symlink.c:39
sysfs_do_create_link_sd+0x83/0x110 fs/sysfs/symlink.c:44
driver_sysfs_add+0x89/0x210 drivers/base/dd.c:442
device_bind_driver+0x17/0x60 drivers/base/dd.c:500
mac80211_hwsim_new_radio+0x4a0/0x5320 drivers/net/wireless/virtual/mac80211_hwsim.c:5436

Memory state around the buggy address:

ffff8880796d9a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8880796d9b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff8880796d9b80: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
^
ffff8880796d9c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8880796d9c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

==================================================================


Tested on:

commit: 22cc16c0 riscv, bpf: Fix incorrect usage of BPF_TRAMP_..
git tree: bpf

console output: https://syzkaller.appspot.com/x/log.txt?x=15cb692a580000

kernel config: https://syzkaller.appspot.com/x/.config?x=a94030c847137a18
dashboard link: https://syzkaller.appspot.com/bug?extid=2c29addf92581b410079
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=12950e9a580000

[syzbot]

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

***

Subject: [PATCH] bpf: Reject BPF_MAP_TYPE_INSN_ARRAY in check_reg_const_str()

Author: karti...@gmail.com

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

BPF_MAP_TYPE_INSN_ARRAY maps store instruction pointers in their
ips array, not string data. The map_direct_value_addr callback for
this map type returns the address of the ips array, which is not
suitable for use as a constant string argument.

When a BPF program passes a pointer to an insn_array map value as
ARG_PTR_TO_CONST_STR (e.g., to bpf_snprintf), the verifier's
null-termination check in check_reg_const_str() operates on the
wrong memory region, and at runtime bpf_bprintf_prepare() can read
out of bounds searching for a null terminator.

Reject BPF_MAP_TYPE_INSN_ARRAY in check_reg_const_str() since this
map type is not designed to hold string data.

Reported-by: syzbot+2c29ad...@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---

kernel/bpf/verifier.c | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index f0ca69f888fa..3135643d5695 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -9609,6 +9609,11 @@ static int check_reg_const_str(struct bpf_verifier_env *env,
if (reg->type != PTR_TO_MAP_VALUE)
return -EINVAL;

+ if (map->map_type == BPF_MAP_TYPE_INSN_ARRAY) {
+ verbose(env, "R%d points to insn_array map which cannot be used as const string\n", regno);
+ return -EACCES;
+ }
+
if (!bpf_map_is_rdonly(map)) {
verbose(env, "R%d does not point to a readonly map'\n", regno);
return -EACCES;
--
2.43.0

[syzbot]

Hello,

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

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

Tested on:

commit: 22cc16c0 riscv, bpf: Fix incorrect usage of BPF_TRAMP_..
git tree: bpf

console output: https://syzkaller.appspot.com/x/log.txt?x=15ef2074580000

kernel config: https://syzkaller.appspot.com/x/.config?x=a94030c847137a18
dashboard link: https://syzkaller.appspot.com/bug?extid=2c29addf92581b410079
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=13a15e9a580000

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

[Edward Adam Davis]

#syz test

diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index db72b96f9c8c..88da2d0e634c 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -827,7 +827,7 @@ int bpf_bprintf_prepare(const char *fmt, u32 fmt_size, const u64 *raw_args,
char fmt_ptype, cur_ip[16], ip_spec[] = "%pXX";

fmt_end = strnchr(fmt, fmt_size, 0);
- if (!fmt_end)
+ if (!fmt_end || fmt_end == fmt)
return -EINVAL;
fmt_size = fmt_end - fmt;

[syzbot]

Hello,

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

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

Tested on:

commit: ab86d0bf selftests/bpf: Update xdp_context_test_run te..
git tree: bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=13c6c1fc580000

kernel config: https://syzkaller.appspot.com/x/.config?x=a94030c847137a18
dashboard link: https://syzkaller.appspot.com/bug?extid=2c29addf92581b410079
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=16ccef92580000

[Edward Adam Davis]

The user constructed a BPF program containing a bpf_snprintf() call.
The fmt parameter passed to bpf_snprintf() was not assigned a value;
it only executed the BPF_MAP_FREEZE command to freeze the fmt string.
Furthermore, when bpf_check() executed check_reg_const_str() and
check_bpf_snprintf_call() to check the fmt input parameter of the
user-constructed BPF program's bpf_snprintf() call, strnchr() only
checked if fmt was a null-terminated string. This led the BPF verifier
to incorrectly assume the constant format string was valid.
When the BPF program was actually executed, the out-of-bounds (OOB)
issue reported by syzbot occurred [1].

This issue is strongly related to bpf_snprintf(), therefore adding a
check for an empty format string in check_bpf_snprintf_call() would
be beneficial. Since it calls bpf_bprintf_prepare(), only adding a
check on the result of strnchr() is needed to prevent the case where
the format string is empty.

[1]

BUG: KASAN: slab-out-of-bounds in strnchr+0x5e/0x80 lib/string.c:405
Read of size 1 at addr ffff888029e093b0 by task ksoftirqd/1/23

Call Trace:

strnchr+0x5e/0x80 lib/string.c:405
bpf_bprintf_prepare+0x167/0x13d0 kernel/bpf/helpers.c:829
____bpf_snprintf kernel/bpf/helpers.c:1065 [inline]
bpf_snprintf+0xd3/0x1b0 kernel/bpf/helpers.c:1049

Allocated by task 6022:

__bpf_map_area_alloc kernel/bpf/syscall.c:395 [inline]
bpf_map_area_alloc+0x64/0x180 kernel/bpf/syscall.c:408
insn_array_alloc+0x52/0x140 kernel/bpf/bpf_insn_array.c:49
map_create+0xafd/0x16a0 kernel/bpf/syscall.c:1514

The buggy address is located 0 bytes to the right of
allocated 944-byte region [ffff888029e09000, ffff888029e093b0)

Fixes: d9c9e4db186a ("bpf: Factorize bpf_trace_printk and bpf_seq_printf")
Reported-by: syzbot+2c29ad...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=2c29addf92581b410079
Tested-by: syzbot+2c29ad...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <ead...@qq.com>
---
kernel/bpf/helpers.c | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

--
2.43.0

[Alexei Starovoitov]

I don't think you root caused it correctly.
The better fix and analysis:
https://patchwork.kernel.org/project/netdevbpf/patch/20260107021037.28...@gmail.com/

pw-bot: cr

[Edward Adam Davis]

On Wed, 7 Jan 2026 19:02:37 -0800, Alexei Starovoitov <alexei.st...@gmail.com> wrote:
> > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> > index db72b96f9c8c..88da2d0e634c 100644
> > --- a/kernel/bpf/helpers.c
> > +++ b/kernel/bpf/helpers.c
> > @@ -827,7 +827,7 @@ int bpf_bprintf_prepare(const char *fmt, u32 fmt_size, const u64 *raw_args,
> > char fmt_ptype, cur_ip[16], ip_spec[] = "%pXX";
> >
> > fmt_end = strnchr(fmt, fmt_size, 0);
> > - if (!fmt_end)
> > + if (!fmt_end || fmt_end == fmt)
> > return -EINVAL;
>
> I don't think you root caused it correctly.
> The better fix and analysis:

I am keeping my analysis and patch.
The root cause of the problem is that the format string does not contain
a null terminator ('\0').
Filtering out map type 0x22 to solve the problem is too hasty, as it
would prevent all instructions from calling functions with constant
string arguments.