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

[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+2c29addf92581b410079@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 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

Forwarded: [PATCH] bpf: Fix double offset in check_reg_const_str()

[syzbot]

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

***

Subject: [PATCH] bpf: Fix double offset in check_reg_const_str()
Author: kartikey406@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+2c29addf92581b410079@syzkaller.appspotmail.com
Fixes: 0b51940729150 ("bpf: Factor out helper check_reg_const_str()")
Signed-off-by: Deepanshu Kartikey <kartikey406@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

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

[syzbot]

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

***

Subject: [PATCH] bpf: Fix double offset in insn_array_map_direct_value_addr()
Author: kartikey406@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+2c29addf92581b410079@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@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

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

[syzbot]

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

***

Subject: [PATCH] bpf: Reject BPF_MAP_TYPE_INSN_ARRAY in check_reg_const_str()
Author: kartikey406@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+2c29addf92581b410079@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@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

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

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

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

[syzbot]

Hello,

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

Reported-by: syzbot+2c29addf92581b410079@syzkaller.appspotmail.com
Tested-by: syzbot+2c29addf92581b410079@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

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

[PATCH] bpf: Format string can't be empty

[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+2c29addf92581b410079@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=2c29addf92581b410079
Tested-by: syzbot+2c29addf92581b410079@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
 kernel/bpf/helpers.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [PATCH] bpf: Format string can't be empty

[Alexei Starovoitov]

On Wed, Jan 7, 2026 at 1:39 AM Edward Adam Davis <eadavis@qq.com> wrote:
>
> 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+2c29addf92581b410079@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=2c29addf92581b410079
> Tested-by: syzbot+2c29addf92581b410079@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
>  kernel/bpf/helpers.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> 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:
https://patchwork.kernel.org/project/netdevbpf/patch/20260107021037.289644-1-kartikey406@gmail.com/

pw-bot: cr

Re: [PATCH] bpf: Format string can't be empty

[Edward Adam Davis]

On Wed, 7 Jan 2026 19:02:37 -0800, Alexei Starovoitov <alexei.starovoitov@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.

Re: [PATCH] bpf: Format string can't be empty

[Alexei Starovoitov]

On Wed, Jan 7, 2026 at 7:52 PM Edward Adam Davis <eadavis@qq.com> wrote:
>
> On Wed, 7 Jan 2026 19:02:37 -0800, Alexei Starovoitov <alexei.starovoitov@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.

If you think it's still possible to construct a program that
passes empty const string into this helper then please craft
a selftest that demonstrates that.