[PATCH bpf v3 0/5] bpf: Fix NULL-ptr-derefs when showing a void BTF type

[PATCH bpf v3 0/5] bpf: Fix NULL-ptr-derefs when showing a void BTF type

[Jiayuan Chen]

This series fixes three NULL-ptr-derefs in BTF handling.

Patch 1 handles the syzbot report. A key-less BTF (btf_key_type_id == 0) used
to be rejected for hash maps, until htab and rhtab gained a ->map_check_btf
(to register a dtor) that does not look at the key, so a key-less hash map is
now accepted. Dumping it through bpffs feeds the key type_id 0 into
btf_type_seq_show() and NULL-derefs in btf_type_show(). Reject it again.

Patches 2 and 3 fix two related, pre-existing crashes reachable via
bpf_snprintf_btf(), which renders a type_id taken straight from the BPF
program against the vmlinux BTF. A "const void" (a modifier resolving to
void) NULL-derefs in btf_modifier_show() - void has no ->show op; a
BTF_KIND_VAR NULL-derefs in btf_var_show() - the vmlinux base BTF has no
resolved_ids. Patch 2 falls back to btf_df_show(), the "<unsupported kind:N>"
placeholder already used for FWD/FUNC/FLOAT/DECL_TAG; patch 3 resolves the
var's type directly, mirroring the existing guard in btf_modifier_show().

Patches 4 and 5 add selftests for the three cases. They are meant to reproduce
the crashes: each deliberately walks the faulting path, so on an unfixed
kernel it oopses the task (and panics it under panic_on_oops). That is
intentional - the tests verify the fix and reproduce the bug - so a static
review flagging them for crashing an unfixed kernel can be ignored.

v2 -> v3: Fold in a third fix for the same class of bug, btf_var_show(),
reported while reviewing v2. Address review comments (Fixes attribution,
verbatim syzbot trace, skip instead of fail).

v1 -> v2: AI reported a pre-exist issue. Let's fold it in this series.

v2: https://lore.kernel.org/bpf/20260830073242.148092-1-jiayuan.chen@linux.dev/
v1: https://lore.kernel.org/bpf/20260828093142.179856-1-jiayuan.chen@linux.dev/

Jiayuan Chen (5):
  bpf: Reject key-less BTF for hash maps
  bpf: Fix NULL-ptr-deref when showing a void BTF type
  bpf: Fix NULL-ptr-deref in btf_var_show()
  selftests/bpf: Add test for key-less BTF hash map
  selftests/bpf: Add test for showing a void BTF type

 kernel/bpf/btf.c                              | 20 ++++-
 kernel/bpf/hashtab.c                          |  8 ++
 .../bpf/prog_tests/btf_map_keyless.c          | 82 +++++++++++++++++++
 .../selftests/bpf/prog_tests/btf_show_void.c  | 81 ++++++++++++++++++
 .../selftests/bpf/progs/btf_show_void.c       | 24 ++++++
 5 files changed, 213 insertions(+), 2 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c
 create mode 100644 tools/testing/selftests/bpf/prog_tests/btf_show_void.c
 create mode 100644 tools/testing/selftests/bpf/progs/btf_show_void.c

-- 
2.43.0

[PATCH bpf v3 1/5] bpf: Reject key-less BTF for hash maps

[Jiayuan Chen]

map_check_btf() allows a key-less BTF (btf_key_type_id == 0) only for
maps that have a ->map_check_btf callback, and leaves the actual
decision to that callback. Hash maps used to have no ->map_check_btf,
so a key-less BTF was rejected outright.

That changed when htab and rhtab gained a ->map_check_btf to register a
dtor - htab in commit 1df97a7453ee ("bpf: Register dtor for freeing
special fields") and rhtab in commit 6905f8601298 ("bpf: Allow special
fields in resizable hashtab"). Neither looks at the key, so a key-less
hash map now passes map_check_btf() and gets created. Reading it back
through bpffs feeds the key type_id 0 into btf_type_seq_show();
btf_type_by_id() returns the void type, kind_ops[BTF_KIND_UNKN] is NULL,
and btf_type_show() dereferences it:

KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
RIP: 0010:btf_type_show+0x223/0x2e0 kernel/bpf/btf.c:8232
Call Trace:
 <TASK>
 btf_type_seq_show_flags+0xca/0x120 kernel/bpf/btf.c:8250
 htab_map_seq_show_elem+0x12e/0x350 kernel/bpf/hashtab.c:1669
 map_seq_show+0x13d/0x1e0 kernel/bpf/inode.c:293
 seq_read_iter+0x93f/0x1270 fs/seq_file.c:196
 seq_read+0x344/0x4d0 fs/seq_file.c:163
 vfs_read+0x1e4/0xb40 fs/read_write.c:572
 __x64_sys_pread64+0x1eb/0x250 fs/read_write.c:769
 do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
 </TASK>

Reject a key-less BTF in htab_map_check_btf() and rhtab_map_check_btf(),
restoring the previous behavior.

Fixes: 1df97a7453ee ("bpf: Register dtor for freeing special fields")
Fixes: 6905f8601298 ("bpf: Allow special fields in resizable hashtab")
Reported-by: syzbot+37b56485bbbf90ad8489@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/6a8f4e88.27659fcc.2ceef7.0008.GAE@google.com/T/
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 kernel/bpf/hashtab.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index d40cb5dd446c..43123424183c 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -530,6 +530,10 @@ static int htab_map_check_btf(struct bpf_map *map, const struct btf *btf,
 {
 	struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
 
+	/* Hash maps have no use for a key-less BTF. */
+	if (btf_type_is_void(key_type))
+		return -EINVAL;
+
 	if (htab_is_prealloc(htab))
 		return 0;
 	/*
@@ -3110,6 +3114,10 @@ static int rhtab_map_check_btf(struct bpf_map *map, const struct btf *btf,
 {
 	struct bpf_rhtab *rhtab = container_of(map, struct bpf_rhtab, map);
 
+	/* Hash maps have no use for a key-less BTF. */
+	if (btf_type_is_void(key_type))
+		return -EINVAL;
+
 	return bpf_ma_set_dtor(map, &rhtab->ma, rhtab_mem_dtor);
 }
 
-- 
2.43.0

Re: [PATCH bpf v3 1/5] bpf: Reject key-less BTF for hash maps

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 3259 bytes --]

> map_check_btf() allows a key-less BTF (btf_key_type_id == 0) only for
> maps that have a ->map_check_btf callback, and leaves the actual
> decision to that callback. Hash maps used to have no ->map_check_btf,
> so a key-less BTF was rejected outright.
>
> That changed when htab and rhtab gained a ->map_check_btf to register a
> dtor - htab in commit 1df97a7453ee ("bpf: Register dtor for freeing
> special fields") and rhtab in commit 6905f8601298 ("bpf: Allow special
> fields in resizable hashtab"). Neither looks at the key, so a key-less
> hash map now passes map_check_btf() and gets created. Reading it back
> through bpffs feeds the key type_id 0 into btf_type_seq_show();
> btf_type_by_id() returns the void type, kind_ops[BTF_KIND_UNKN] is NULL,
> and btf_type_show() dereferences it:
>
> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
> RIP: 0010:btf_type_show+0x223/0x2e0 kernel/bpf/btf.c:8232
> Call Trace:
>  <TASK>
>  btf_type_seq_show_flags+0xca/0x120 kernel/bpf/btf.c:8250
>  htab_map_seq_show_elem+0x12e/0x350 kernel/bpf/hashtab.c:1669
>  map_seq_show+0x13d/0x1e0 kernel/bpf/inode.c:293
>  seq_read_iter+0x93f/0x1270 fs/seq_file.c:196
>  seq_read+0x344/0x4d0 fs/seq_file.c:163
>  vfs_read+0x1e4/0xb40 fs/read_write.c:572
>  __x64_sys_pread64+0x1eb/0x250 fs/read_write.c:769
>  do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>  </TASK>

The call trace appears to be edited from the original syzbot report.
The original report (6a8f4e88.27659fcc.2ceef7.0008.GAE@google.com)
includes these additional frames between map_seq_show and seq_read_iter:

  traverse.part.0.constprop.0+0x107/0x650 fs/seq_file.c:112
  traverse fs/seq_file.c:99 [inline]

and also includes the inline frames for the pread64 syscall path:

  ksys_pread64 fs/read_write.c:760 [inline]
  __do_sys_pread64 fs/read_write.c:769 [inline]
  __se_sys_pread64 fs/read_write.c:766 [inline]

The trace shows the crash happened during seq_file traverse() (the pread64
offset walk) rather than a plain forward read. Could the commit message
either restore these frames or mark the trace as trimmed?

> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index d8db1cebc1936..855cab4e1bd7d 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -530,6 +530,10 @@ static int htab_map_check_btf(struct bpf_map *map, const struct btf *btf,
>  {
>  	struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
>
> +	/* Hash maps have no use for a key-less BTF. */
> +	if (btf_type_is_void(key_type))
> +		return -EINVAL;
> +
>  	if (htab_is_prealloc(htab))
>  		return 0;
>  	/*
> @@ -3111,6 +3115,10 @@ static int rhtab_map_check_btf(struct bpf_map *map, const struct btf *btf,
>  {
>  	struct bpf_rhtab *rhtab = container_of(map, struct bpf_rhtab, map);
>
> +	/* Hash maps have no use for a key-less BTF. */
> +	if (btf_type_is_void(key_type))
> +		return -EINVAL;
> +
>  	return bpf_ma_set_dtor(map, &rhtab->ma, rhtab_mem_dtor);
>  }
>


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/33385673160

Re: [PATCH bpf v3 1/5] bpf: Reject key-less BTF for hash maps

[Jiayuan Chen]

在 8/31/26 8:05 PM, bot+bpf-ci@kernel.org 写道:
>> map_check_btf() allows a key-less BTF (btf_key_type_id == 0) only for
>> maps that have a ->map_check_btf callback, and leaves the actual
>> decision to that callback. Hash maps used to have no ->map_check_btf,
>> so a key-less BTF was rejected outright.
>>
>> That changed when htab and rhtab gained a ->map_check_btf to register a
>> dtor - htab in commit 1df97a7453ee ("bpf: Register dtor for freeing
>> special fields") and rhtab in commit 6905f8601298 ("bpf: Allow special
>> fields in resizable hashtab"). Neither looks at the key, so a key-less
>> hash map now passes map_check_btf() and gets created. Reading it back
>> through bpffs feeds the key type_id 0 into btf_type_seq_show();
>> btf_type_by_id() returns the void type, kind_ops[BTF_KIND_UNKN] is NULL,
>> and btf_type_show() dereferences it:
>>
>> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
>> RIP: 0010:btf_type_show+0x223/0x2e0 kernel/bpf/btf.c:8232
>> Call Trace:
>>   <TASK>
>>   btf_type_seq_show_flags+0xca/0x120 kernel/bpf/btf.c:8250
>>   htab_map_seq_show_elem+0x12e/0x350 kernel/bpf/hashtab.c:1669
>>   map_seq_show+0x13d/0x1e0 kernel/bpf/inode.c:293
>>   seq_read_iter+0x93f/0x1270 fs/seq_file.c:196
>>   seq_read+0x344/0x4d0 fs/seq_file.c:163
>>   vfs_read+0x1e4/0xb40 fs/read_write.c:572
>>   __x64_sys_pread64+0x1eb/0x250 fs/read_write.c:769
>>   do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
>>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
>>   </TASK>
> The call trace appears to be edited from the original syzbot report.
> The original report (6a8f4e88.27659fcc.2ceef7.0008.GAE@google.com)
> includes these additional frames between map_seq_show and seq_read_iter:
>
>    traverse.part.0.constprop.0+0x107/0x650 fs/seq_file.c:112
>    traverse fs/seq_file.c:99 [inline]
>
> and also includes the inline frames for the pread64 syscall path:
>
>    ksys_pread64 fs/read_write.c:760 [inline]
>    __do_sys_pread64 fs/read_write.c:769 [inline]
>    __se_sys_pread64 fs/read_write.c:766 [inline]


I edited it intentional‌ly to avoid breaking the format rule.

Re: [PATCH bpf v3 1/5] bpf: Reject key-less BTF for hash maps

[Ihor Solodrai]

On 8/31/26 4:01 AM, Jiayuan Chen wrote:
> map_check_btf() allows a key-less BTF (btf_key_type_id == 0) only for
> maps that have a ->map_check_btf callback, and leaves the actual
> decision to that callback. Hash maps used to have no ->map_check_btf,
> so a key-less BTF was rejected outright.
> 
> That changed when htab and rhtab gained a ->map_check_btf to register a
> dtor - htab in commit 1df97a7453ee ("bpf: Register dtor for freeing
> special fields") and rhtab in commit 6905f8601298 ("bpf: Allow special
> fields in resizable hashtab"). Neither looks at the key, so a key-less
> hash map now passes map_check_btf() and gets created. Reading it back
> through bpffs feeds the key type_id 0 into btf_type_seq_show();
> btf_type_by_id() returns the void type, kind_ops[BTF_KIND_UNKN] is NULL,
> and btf_type_show() dereferences it:
> 
> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
> RIP: 0010:btf_type_show+0x223/0x2e0 kernel/bpf/btf.c:8232
> Call Trace:
>  <TASK>
>  btf_type_seq_show_flags+0xca/0x120 kernel/bpf/btf.c:8250
>  htab_map_seq_show_elem+0x12e/0x350 kernel/bpf/hashtab.c:1669
>  map_seq_show+0x13d/0x1e0 kernel/bpf/inode.c:293
>  seq_read_iter+0x93f/0x1270 fs/seq_file.c:196
>  seq_read+0x344/0x4d0 fs/seq_file.c:163
>  vfs_read+0x1e4/0xb40 fs/read_write.c:572
>  __x64_sys_pread64+0x1eb/0x250 fs/read_write.c:769
>  do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>  </TASK>
> 
> Reject a key-less BTF in htab_map_check_btf() and rhtab_map_check_btf(),
> restoring the previous behavior.
> 
> Fixes: 1df97a7453ee ("bpf: Register dtor for freeing special fields")
> Fixes: 6905f8601298 ("bpf: Allow special fields in resizable hashtab")
> Reported-by: syzbot+37b56485bbbf90ad8489@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/6a8f4e88.27659fcc.2ceef7.0008.GAE@google.com/T/
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
>  kernel/bpf/hashtab.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index d40cb5dd446c..43123424183c 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -530,6 +530,10 @@ static int htab_map_check_btf(struct bpf_map *map, const struct btf *btf,
>  {
>  	struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
>  
> +	/* Hash maps have no use for a key-less BTF. */

nit: I think this comment is unnecessary in both places.

Other than that the fix makes sense to me, thanks.

Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev>

> +	if (btf_type_is_void(key_type))
> +		return -EINVAL;
> +
>  	if (htab_is_prealloc(htab))
>  		return 0;
>  	/*
> @@ -3110,6 +3114,10 @@ static int rhtab_map_check_btf(struct bpf_map *map, const struct btf *btf,
>  {
>  	struct bpf_rhtab *rhtab = container_of(map, struct bpf_rhtab, map);
>  
> +	/* Hash maps have no use for a key-less BTF. */
> +	if (btf_type_is_void(key_type))
> +		return -EINVAL;
> +
>  	return bpf_ma_set_dtor(map, &rhtab->ma, rhtab_mem_dtor);
>  }
>  

[PATCH bpf v3 2/5] bpf: Fix NULL-ptr-deref when showing a void BTF type

[Jiayuan Chen]

btf_modifier_show() resolves the modifier and then calls
btf_type_ops(t)->show() unconditionally. For the void type (type_id 0,
BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL.

The map dump path cannot reach a void type (a map key/value must have a
size and void has none), but bpf_snprintf_btf() takes a type_id straight
from the BPF program, and a "const void" (a modifier that resolves to
void, present in the vmlinux BTF) NULL-derefs there:

KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
RIP: 0010:btf_modifier_show (kernel/bpf/btf.c:2914)
Call Trace:
 <TASK>
 btf_type_show (kernel/bpf/btf.c:8251)
 btf_type_snprintf_show (kernel/bpf/btf.c:8321)
 bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047)
 bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829)
 __sys_bpf (kernel/bpf/syscall.c:4804)
 do_syscall_64 (arch/x86/entry/syscall_64.c:94)
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
 </TASK>

void has no size, so there is nothing to render - not even a byte length
to fall back to dumping as raw hex. btf_df_show() is already the ->show
for the other kinds that carry no value to print - FWD, FUNC, FUNC_PROTO,
FLOAT and DECL_TAG - and emits an "<unsupported kind:N>" placeholder;
void belongs to the same group and only lacks a show op because it has
no kind_ops[] entry at all. Fall back to btf_df_show() in
btf_modifier_show() when the resolved type has no show op, so a void type
prints that placeholder instead of crashing; bpf_snprintf_btf() then
returns the length as usual.

Fixes: c4d0bfb45068 ("bpf: Add bpf_snprintf_btf helper")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 kernel/bpf/btf.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 91b8ce77f699..6e267c4c4e1f 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -2911,7 +2911,15 @@ static void btf_modifier_show(const struct btf *btf,
 	else
 		t = btf_type_skip_modifiers(btf, type_id, NULL);
 
-	btf_type_ops(t)->show(btf, t, type_id, data, bits_offset, show);
+	/*
+	 * A modifier can resolve to the void type (e.g. "const void"), which
+	 * has no show op (kind_ops[BTF_KIND_UNKN] is NULL). Print a placeholder
+	 * instead of dereferencing NULL.
+	 */
+	if (!btf_type_ops(t))
+		btf_df_show(btf, t, type_id, data, bits_offset, show);
+	else
+		btf_type_ops(t)->show(btf, t, type_id, data, bits_offset, show);
 }
 
 static void btf_var_show(const struct btf *btf, const struct btf_type *t,
-- 
2.43.0

Re: [PATCH bpf v3 2/5] bpf: Fix NULL-ptr-deref when showing a void BTF type

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 2781 bytes --]

> bpf: Fix NULL-ptr-deref when showing a void BTF type
>
> btf_modifier_show() resolves the modifier and then calls
> btf_type_ops(t)->show() unconditionally. For the void type (type_id 0,
> BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL.
>
> The map dump path cannot reach a void type (a map key/value must have a
> size and void has none), but bpf_snprintf_btf() takes a type_id straight
> from the BPF program, and a "const void" (a modifier that resolves to
> void, present in the vmlinux BTF) NULL-derefs there:

Is this statement about the map dump path accurate? Looking at
map_check_btf() in kernel/bpf/syscall.c, a map key isn't required to
have a size:

	/* Some maps allow key to be unspecified. */
	if (btf_key_id) {
		key_type = btf_type_id_size(btf, &btf_key_id, &key_size);
		if (!key_type || key_size != map->key_size)
			return -EINVAL;
	} else {
		key_type = btf_type_by_id(btf, 0);
		if (!map->ops->map_check_btf)
			return -EINVAL;
	}

When btf_key_id is 0, key_type is set to the void type, and
map->btf_key_type_id is stored as 0. array_map_check_btf() even has a
dedicated keyless exception ("One exception for keyless BTF:
.bss/.data/.rodata/.percpu map").

The preceding patch in this series, commit 55f5ad8f45a5 ("bpf: Reject
key-less BTF for hash maps"), documents a syzbot NULL-ptr-deref where a
void key reached the map dump path through htab_map_seq_show_elem() ->
btf_type_seq_show_flags() -> btf_type_show() -> kind_ops[BTF_KIND_UNKN]
== NULL. That patch closed the path by adding btf_type_is_void(key_type)
rejections in htab_map_check_btf() and rhtab_map_check_btf().

Would it be more accurate to say the map dump path is closed by the
preceding patch and by existing btf_key_type_id guards, rather than by
a size requirement?

> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -2911,7 +2911,15 @@ static void btf_modifier_show(const struct btf *btf,
>  	else
>  		t = btf_type_skip_modifiers(btf, type_id, NULL);
>
> -	btf_type_ops(t)->show(btf, t, type_id, data, bits_offset, show);
> +	/*
> +	 * A modifier can resolve to the void type (e.g. "const void"), which
> +	 * has no show op (kind_ops[BTF_KIND_UNKN] is NULL). Print a placeholder
> +	 * instead of dereferencing NULL.
> +	 */
> +	if (!btf_type_ops(t))
> +		btf_df_show(btf, t, type_id, data, bits_offset, show);
> +	else
> +		btf_type_ops(t)->show(btf, t, type_id, data, bits_offset, show);
>  }
>
>  static void btf_var_show(const struct btf *btf, const struct btf_type *t,


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/33385673160

Re: [PATCH bpf v3 2/5] bpf: Fix NULL-ptr-deref when showing a void BTF type

[Jiayuan Chen]

在 8/31/26 7:48 PM, bot+bpf-ci@kernel.org 写道:
>> bpf: Fix NULL-ptr-deref when showing a void BTF type
>>
>> btf_modifier_show() resolves the modifier and then calls
>> btf_type_ops(t)->show() unconditionally. For the void type (type_id 0,
>> BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL.
>>
>> The map dump path cannot reach a void type (a map key/value must have a
>> size and void has none), but bpf_snprintf_btf() takes a type_id straight
>> from the BPF program, and a "const void" (a modifier that resolves to
>> void, present in the vmlinux BTF) NULL-derefs there:
> Is this statement about the map dump path accurate? Looking at
> map_check_btf() in kernel/bpf/syscall.c, a map key isn't required to
> have a size:
>
> 	/* Some maps allow key to be unspecified. */
> 	if (btf_key_id) {
> 		key_type = btf_type_id_size(btf, &btf_key_id, &key_size);
> 		if (!key_type || key_size != map->key_size)
> 			return -EINVAL;
> 	} else {
> 		key_type = btf_type_by_id(btf, 0);
> 		if (!map->ops->map_check_btf)
> 			return -EINVAL;
> 	}
>
> When btf_key_id is 0, key_type is set to the void type, and
> map->btf_key_type_id is stored as 0. array_map_check_btf() even has a
> dedicated keyless exception ("One exception for keyless BTF:
> .bss/.data/.rodata/.percpu map").
>
> The preceding patch in this series, commit 55f5ad8f45a5 ("bpf: Reject
> key-less BTF for hash maps"), documents a syzbot NULL-ptr-deref where a
> void key reached the map dump path through htab_map_seq_show_elem() ->
> btf_type_seq_show_flags() -> btf_type_show() -> kind_ops[BTF_KIND_UNKN]
> == NULL. That patch closed the path by adding btf_type_is_void(key_type)
> rejections in htab_map_check_btf() and rhtab_map_check_btf().
>
> Would it be more accurate to say the map dump path is closed by the
> preceding patch and by existing btf_key_type_id guards, rather than by
> a size requirement?



I still think I am correct.

A "const void" (a nonzero-id modifier) is rejected as key/value by 
map_check_btf()'s size check;
your key-less case is a bare void key (id 0) on a different path, 
already handled by
patch 1 — so the size reasoning holds here.

Re: [PATCH bpf v3 2/5] bpf: Fix NULL-ptr-deref when showing a void BTF type

[Ihor Solodrai]

On 8/31/26 4:01 AM, Jiayuan Chen wrote:
> btf_modifier_show() resolves the modifier and then calls
> btf_type_ops(t)->show() unconditionally. For the void type (type_id 0,
> BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL.
> 
> The map dump path cannot reach a void type (a map key/value must have a
> size and void has none), but bpf_snprintf_btf() takes a type_id straight
> from the BPF program, and a "const void" (a modifier that resolves to
> void, present in the vmlinux BTF) NULL-derefs there:
> 
> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
> RIP: 0010:btf_modifier_show (kernel/bpf/btf.c:2914)
> Call Trace:
>  <TASK>
>  btf_type_show (kernel/bpf/btf.c:8251)
>  btf_type_snprintf_show (kernel/bpf/btf.c:8321)
>  bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047)
>  bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829)
>  __sys_bpf (kernel/bpf/syscall.c:4804)
>  do_syscall_64 (arch/x86/entry/syscall_64.c:94)
>  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
>  </TASK>
> 
> void has no size, so there is nothing to render - not even a byte length
> to fall back to dumping as raw hex. btf_df_show() is already the ->show
> for the other kinds that carry no value to print - FWD, FUNC, FUNC_PROTO,
> FLOAT and DECL_TAG - and emits an "<unsupported kind:N>" placeholder;
> void belongs to the same group and only lacks a show op because it has
> no kind_ops[] entry at all. Fall back to btf_df_show() in
> btf_modifier_show() when the resolved type has no show op, so a void type
> prints that placeholder instead of crashing; bpf_snprintf_btf() then
> returns the length as usual.

nit: The explanation is a bit too verbose, I'd try simplifying. And the
comment in the code as well.

> 
> Fixes: c4d0bfb45068 ("bpf: Add bpf_snprintf_btf helper")
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
>  kernel/bpf/btf.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 91b8ce77f699..6e267c4c4e1f 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -2911,7 +2911,15 @@ static void btf_modifier_show(const struct btf *btf,
>  	else
>  		t = btf_type_skip_modifiers(btf, type_id, NULL);
>  
> -	btf_type_ops(t)->show(btf, t, type_id, data, bits_offset, show);
> +	/*
> +	 * A modifier can resolve to the void type (e.g. "const void"), which
> +	 * has no show op (kind_ops[BTF_KIND_UNKN] is NULL). Print a placeholder
> +	 * instead of dereferencing NULL.
> +	 */
> +	if (!btf_type_ops(t))
> +		btf_df_show(btf, t, type_id, data, bits_offset, show);
> +	else
> +		btf_type_ops(t)->show(btf, t, type_id, data, bits_offset, show);

Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev>

>  }
>  
>  static void btf_var_show(const struct btf *btf, const struct btf_type *t,

[PATCH bpf v3 3/5] bpf: Fix NULL-ptr-deref in btf_var_show()

[Jiayuan Chen]

btf_var_show() calls btf_type_id_resolve() unconditionally, which
dereferences btf->resolved_ids. That is NULL for a base BTF - e.g. the
vmlinux BTF that bpf_snprintf_btf() renders against - since base BTF is
not resolved during parsing. btf_modifier_show() guards this with
'if (btf->resolved_ids)', but btf_var_show() does not.

A BPF program that passes the type_id of a BTF_KIND_VAR from the vmlinux
BTF to bpf_snprintf_btf() thus NULL-derefs:

KASAN: probably user-memory-access in range [0x46638-0x4663f]
RIP: 0010:btf_var_show (kernel/bpf/btf.c:2929)
Call Trace:
 <TASK>
 btf_type_show (kernel/bpf/btf.c:8259)
 btf_type_snprintf_show (kernel/bpf/btf.c:8329)
 bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047)
 bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829)
 __sys_bpf (kernel/bpf/syscall.c:4804)
 do_syscall_64 (arch/x86/entry/syscall_64.c:84)
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
 </TASK>

Resolve the var's type directly with btf_type_skip_modifiers() when
resolved_ids is NULL, mirroring btf_modifier_show().

Fixes: c4d0bfb45068 ("bpf: Add bpf_snprintf_btf helper")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 kernel/bpf/btf.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 6e267c4c4e1f..3cf35ee49c10 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -2926,7 +2926,15 @@ static void btf_var_show(const struct btf *btf, const struct btf_type *t,
 			 u32 type_id, void *data, u8 bits_offset,
 			 struct btf_show *show)
 {
-	t = btf_type_id_resolve(btf, &type_id);
+	/*
+	 * btf_type_id_resolve() dereferences btf->resolved_ids, which is NULL
+	 * for a base BTF (e.g. the vmlinux BTF that bpf_snprintf_btf() uses).
+	 * Resolve the var's type directly in that case.
+	 */
+	if (btf->resolved_ids)
+		t = btf_type_id_resolve(btf, &type_id);
+	else
+		t = btf_type_skip_modifiers(btf, t->type, &type_id);
 
 	btf_type_ops(t)->show(btf, t, type_id, data, bits_offset, show);
 }
-- 
2.43.0

Re: [PATCH bpf v3 3/5] bpf: Fix NULL-ptr-deref in btf_var_show()

[Ihor Solodrai]

On 8/31/26 4:01 AM, Jiayuan Chen wrote:
> btf_var_show() calls btf_type_id_resolve() unconditionally, which
> dereferences btf->resolved_ids. That is NULL for a base BTF - e.g. the
> vmlinux BTF that bpf_snprintf_btf() renders against - since base BTF is
> not resolved during parsing. btf_modifier_show() guards this with
> 'if (btf->resolved_ids)', but btf_var_show() does not.
> 
> A BPF program that passes the type_id of a BTF_KIND_VAR from the vmlinux
> BTF to bpf_snprintf_btf() thus NULL-derefs:
> 
> KASAN: probably user-memory-access in range [0x46638-0x4663f]
> RIP: 0010:btf_var_show (kernel/bpf/btf.c:2929)
> Call Trace:
>  <TASK>
>  btf_type_show (kernel/bpf/btf.c:8259)
>  btf_type_snprintf_show (kernel/bpf/btf.c:8329)
>  bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047)
>  bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829)
>  __sys_bpf (kernel/bpf/syscall.c:4804)
>  do_syscall_64 (arch/x86/entry/syscall_64.c:84)
>  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
>  </TASK>
> 
> Resolve the var's type directly with btf_type_skip_modifiers() when
> resolved_ids is NULL, mirroring btf_modifier_show().
> 
> Fixes: c4d0bfb45068 ("bpf: Add bpf_snprintf_btf helper")
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
>  kernel/bpf/btf.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 6e267c4c4e1f..3cf35ee49c10 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -2926,7 +2926,15 @@ static void btf_var_show(const struct btf *btf, const struct btf_type *t,
>  			 u32 type_id, void *data, u8 bits_offset,
>  			 struct btf_show *show)
>  {
> -	t = btf_type_id_resolve(btf, &type_id);
> +	/*
> +	 * btf_type_id_resolve() dereferences btf->resolved_ids, which is NULL
> +	 * for a base BTF (e.g. the vmlinux BTF that bpf_snprintf_btf() uses).
> +	 * Resolve the var's type directly in that case.
> +	 */
> +	if (btf->resolved_ids)
> +		t = btf_type_id_resolve(btf, &type_id);
> +	else
> +		t = btf_type_skip_modifiers(btf, t->type, &type_id);

Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev>

>  
>  	btf_type_ops(t)->show(btf, t, type_id, data, bits_offset, show);
>  }

[PATCH bpf v3 4/5] selftests/bpf: Add test for key-less BTF hash map

[Jiayuan Chen]

Create a hash and an rhash map with btf_key_type_id == 0 and expect
bpf_map_create() to fail with -EINVAL; a positive control with a real
key type confirms the rejection is about the key-less BTF. On an unfixed
kernel the map is created, and the test pins and reads it back to walk
the bpffs dump path, which reproduces the btf_type_show() NULL-deref - so
running it on an unfixed kernel oopses the reading task (and panics it
under panic_on_oops).

Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 .../bpf/prog_tests/btf_map_keyless.c          | 82 +++++++++++++++++++
 1 file changed, 82 insertions(+)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c

diff --git a/tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c b/tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c
new file mode 100644
index 000000000000..a7d037f57a7e
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <test_progs.h>
+#include <bpf/btf.h>
+
+/*
+ * A hash map with a key-less BTF (btf_key_type_id == 0) used to NULL-deref in
+ * btf_type_show() when dumped via bpffs.
+ * A fixed kernel rejects such a map at creation; on an unfixed kernel the
+ * pin-and-read below deliberately walks that bpffs dump path, so it doubles
+ * as a reproducer: it oopses an unfixed kernel (and panics it under
+ * panic_on_oops).
+ */
+static void check_keyless(int map_type, __u32 map_flags, int btf_fd, int val_id)
+{
+	LIBBPF_OPTS(bpf_map_create_opts, opts);
+	const char *path = "/sys/fs/bpf/keyless_map";
+	__u32 key = 1, val = 0x41424344;
+	char buf[256];
+	int map_fd;
+	FILE *f;
+
+	opts.map_flags = map_flags;
+	opts.btf_fd = btf_fd;
+	opts.btf_value_type_id = val_id;
+
+	/*
+	 * Positive control: the same map with a real key type must be accepted,
+	 * so the -EINVAL below is about the key-less BTF and not some unrelated
+	 * rejection (e.g. an unknown map type).
+	 */
+	opts.btf_key_type_id = val_id;
+	map_fd = bpf_map_create(map_type, "keyed_map", 4, 4, 8, &opts);
+	if (!ASSERT_GE(map_fd, 0, "keyed create is accepted"))
+		return;
+	close(map_fd);
+
+	/* A key-less BTF must be rejected. */
+	opts.btf_key_type_id = 0;
+	map_fd = bpf_map_create(map_type, "keyless_map", 4, 4, 8, &opts);
+
+	if (map_fd >= 0) {
+		/* Unfixed kernel: reproduce the oops via the bpffs dump path. */
+		(void)bpf_map_update_elem(map_fd, &key, &val, 0);
+		if (bpf_obj_pin(map_fd, path) == 0) {
+			f = fopen(path, "r");
+			if (f) {
+				while (fgets(buf, sizeof(buf), f))
+					;
+				fclose(f);
+			}
+			unlink(path);
+		}
+		close(map_fd);
+	}
+
+	ASSERT_EQ(map_fd, -EINVAL, "key-less create is rejected");
+}
+
+void test_btf_map_keyless(void)
+{
+	int btf_fd, val_id;
+	struct btf *btf;
+
+	btf = btf__new_empty();
+	if (!ASSERT_OK_PTR(btf, "btf__new_empty"))
+		return;
+
+	val_id = btf__add_int(btf, "int", 4, BTF_INT_SIGNED);
+	if (!ASSERT_GT(val_id, 0, "btf__add_int"))
+		goto out;
+
+	if (!ASSERT_OK(btf__load_into_kernel(btf), "btf__load_into_kernel"))
+		goto out;
+	btf_fd = btf__fd(btf);
+
+	if (test__start_subtest("hash"))
+		check_keyless(BPF_MAP_TYPE_HASH, 0, btf_fd, val_id);
+	if (test__start_subtest("rhash"))
+		check_keyless(BPF_MAP_TYPE_RHASH, BPF_F_NO_PREALLOC, btf_fd, val_id);
+out:
+	btf__free(btf);
+}
-- 
2.43.0

Re: [PATCH bpf v3 4/5] selftests/bpf: Add test for key-less BTF hash map

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]

> diff --git a/tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c b/tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c
> new file mode 100644
> index 0000000000000..a7d037f57a7ef
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c
> @@ -0,0 +1,82 @@

[ ... ]

> +	/*
> +	 * Positive control: the same map with a real key type must be accepted,
> +	 * so the -EINVAL below is about the key-less BTF and not some unrelated
> +	 * rejection (e.g. an unknown map type).
> +	 */
> +	opts.btf_key_type_id = val_id;
> +	map_fd = bpf_map_create(map_type, "keyed_map", 4, 4, 8, &opts);
> +	if (!ASSERT_GE(map_fd, 0, "keyed create is accepted"))
> +		return;
> +	close(map_fd);

A subsystem pattern flags this as potentially concerning: the positive
control turns "this kernel does not implement the map type" into a hard test
failure instead of a skip.

BPF_MAP_TYPE_RHASH (used by the rhash subtest) is new; on any kernel that
lacks it, map_create() rejects the unknown map type and this ASSERT_GE fails,
reporting a red btf_map_keyless/rhash that has nothing to do with the
behaviour under test.

libbpf already provides the probe for this: libbpf_probe_bpf_map_type()
handles BPF_MAP_TYPE_RHASH explicitly (tools/lib/bpf/libbpf_probes.c:312,
including the BPF_F_NO_PREALLOC requirement), so the subtest could probe
and test__skip() with a reason instead.

Two arguments in the patch's favour: (a) an unknown map type is rejected with
-EINVAL, not EOPNOTSUPP/ENOSYS, so the errno match isn't literal; (b) the
comment on lines 26-30 shows the failure is deliberate - the author wants an
unrelated rejection to surface as a failed positive control rather than be
silently swallowed by the -EINVAL assertion below.

Both arguments are about the choice of signal, not about whether an absent map
type is a capability-absent condition, which it is. Does the current approach
fit the test's intent better than probing and skipping?

[ ... ]

> +	if (test__start_subtest("hash"))
> +		check_keyless(BPF_MAP_TYPE_HASH, 0, btf_fd, val_id);
> +	if (test__start_subtest("rhash"))
> +		check_keyless(BPF_MAP_TYPE_RHASH, BPF_F_NO_PREALLOC, btf_fd, val_id);


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/33385673160

Re: [PATCH bpf v3 4/5] selftests/bpf: Add test for key-less BTF hash map

[Jiayuan Chen]

在 8/31/26 7:48 PM, bot+bpf-ci@kernel.org 写道:
>> diff --git a/tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c b/tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c
>> new file mode 100644
>> index 0000000000000..a7d037f57a7ef
>> --- /dev/null
>> +++ b/tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c
>> @@ -0,0 +1,82 @@
> [ ... ]
>
>> +	/*
>> +	 * Positive control: the same map with a real key type must be accepted,
>> +	 * so the -EINVAL below is about the key-less BTF and not some unrelated
>> +	 * rejection (e.g. an unknown map type).
>> +	 */
>> +	opts.btf_key_type_id = val_id;
>> +	map_fd = bpf_map_create(map_type, "keyed_map", 4, 4, 8, &opts);
>> +	if (!ASSERT_GE(map_fd, 0, "keyed create is accepted"))
>> +		return;
>> +	close(map_fd);
> A subsystem pattern flags this as potentially concerning: the positive
> control turns "this kernel does not implement the map type" into a hard test
> failure instead of a skip.
>
> BPF_MAP_TYPE_RHASH (used by the rhash subtest) is new; on any kernel that
> lacks it, map_create() rejects the unknown map type and this ASSERT_GE fails,
> reporting a red btf_map_keyless/rhash that has nothing to do with the
> behaviour under test.

Selftests run against the matching kernel, where the map type exists, so 
this doesn't happen.

Re: [PATCH bpf v3 4/5] selftests/bpf: Add test for key-less BTF hash map

[Ihor Solodrai]

On 8/31/26 4:01 AM, Jiayuan Chen wrote:
> Create a hash and an rhash map with btf_key_type_id == 0 and expect
> bpf_map_create() to fail with -EINVAL; a positive control with a real
> key type confirms the rejection is about the key-less BTF. On an unfixed
> kernel the map is created, and the test pins and reads it back to walk
> the bpffs dump path, which reproduces the btf_type_show() NULL-deref - so
> running it on an unfixed kernel oopses the reading task (and panics it
> under panic_on_oops).
> 
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
>  .../bpf/prog_tests/btf_map_keyless.c          | 82 +++++++++++++++++++
>  1 file changed, 82 insertions(+)
>  create mode 100644 tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c
> 
> diff --git a/tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c b/tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c
> new file mode 100644
> index 000000000000..a7d037f57a7e
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c
> @@ -0,0 +1,82 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <test_progs.h>
> +#include <bpf/btf.h>
> +
> +/*
> + * A hash map with a key-less BTF (btf_key_type_id == 0) used to NULL-deref in
> + * btf_type_show() when dumped via bpffs.
> + * A fixed kernel rejects such a map at creation; on an unfixed kernel the
> + * pin-and-read below deliberately walks that bpffs dump path, so it doubles
> + * as a reproducer: it oopses an unfixed kernel (and panics it under
> + * panic_on_oops).
> + */
> +static void check_keyless(int map_type, __u32 map_flags, int btf_fd, int val_id)
> +{
> +	LIBBPF_OPTS(bpf_map_create_opts, opts);
> +	const char *path = "/sys/fs/bpf/keyless_map";
> +	__u32 key = 1, val = 0x41424344;
> +	char buf[256];
> +	int map_fd;
> +	FILE *f;
> +
> +	opts.map_flags = map_flags;
> +	opts.btf_fd = btf_fd;
> +	opts.btf_value_type_id = val_id;
> +
> +	/*
> +	 * Positive control: the same map with a real key type must be accepted,
> +	 * so the -EINVAL below is about the key-less BTF and not some unrelated
> +	 * rejection (e.g. an unknown map type).
> +	 */
> +	opts.btf_key_type_id = val_id;
> +	map_fd = bpf_map_create(map_type, "keyed_map", 4, 4, 8, &opts);
> +	if (!ASSERT_GE(map_fd, 0, "keyed create is accepted"))
> +		return;
> +	close(map_fd);
> +
> +	/* A key-less BTF must be rejected. */
> +	opts.btf_key_type_id = 0;
> +	map_fd = bpf_map_create(map_type, "keyless_map", 4, 4, 8, &opts);
> +
> +	if (map_fd >= 0) {
> +		/* Unfixed kernel: reproduce the oops via the bpffs dump path. */
> +		(void)bpf_map_update_elem(map_fd, &key, &val, 0);
> +		if (bpf_obj_pin(map_fd, path) == 0) {
> +			f = fopen(path, "r");
> +			if (f) {
> +				while (fgets(buf, sizeof(buf), f))
> +					;
> +				fclose(f);
> +			}
> +			unlink(path);
> +		}
> +		close(map_fd);
> +	}

The whole `if (map_fd >= 0) { ... }` block can be dropped.

If the map has been accepted (0 instead of -EINVAL), it already catches the bug.
It's unnecessary to reproduce the NULL ptr splat.

pw-bot: cr

Also, I think it would be useful to refactor and extend existing
selftests that were added for the features (for example an old
prog_tests/snprintf_btf.c), instead of adding a new test program for
every regression case. Not a blocker, but an effort in that direction
would be much appreciated.

Thanks!

> +
> +	ASSERT_EQ(map_fd, -EINVAL, "key-less create is rejected");
> +}
> +
> [...]

[PATCH bpf v3 5/5] selftests/bpf: Add test for showing a void BTF type

[Jiayuan Chen]

Call bpf_snprintf_btf() with type_ids from the vmlinux BTF that used to
NULL-deref in the BTF show path: a "const void" (checked to render the
"<unsupported kind:0>" placeholder) and a BTF_KIND_VAR (checked to render
without crashing). On an unfixed kernel each oopses the task (and panics
it under panic_on_oops), so the test doubles as a reproducer.

Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 .../selftests/bpf/prog_tests/btf_show_void.c  | 81 +++++++++++++++++++
 .../selftests/bpf/progs/btf_show_void.c       | 24 ++++++
 2 files changed, 105 insertions(+)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/btf_show_void.c
 create mode 100644 tools/testing/selftests/bpf/progs/btf_show_void.c

diff --git a/tools/testing/selftests/bpf/prog_tests/btf_show_void.c b/tools/testing/selftests/bpf/prog_tests/btf_show_void.c
new file mode 100644
index 000000000000..d73232dc2a04
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/btf_show_void.c
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <test_progs.h>
+#include <bpf/btf.h>
+#include "btf_show_void.skel.h"
+
+/*
+ * bpf_snprintf_btf() renders a type_id taken straight from the vmlinux BTF.
+ * Two such type_ids used to NULL-deref in the BTF show path:
+ *   - a "const void" (a modifier resolving to void) in btf_modifier_show()
+ *   - a BTF_KIND_VAR in btf_var_show() (base BTF has no resolved_ids)
+ * A fixed kernel renders both without crashing.
+ */
+static long run(struct btf_show_void *skel, __u32 type_id)
+{
+	LIBBPF_OPTS(bpf_test_run_opts, topts);
+	char ctx[8] = {};
+
+	skel->bss->type_id = type_id;
+	topts.ctx_in = ctx;
+	topts.ctx_size_in = sizeof(ctx);
+	if (!ASSERT_OK(bpf_prog_test_run_opts(bpf_program__fd(skel->progs.dump_type),
+					      &topts), "test_run"))
+		return -1;
+	return skel->bss->ret;
+}
+
+void test_btf_show_void(void)
+{
+	const struct btf_type *t;
+	struct btf_show_void *skel;
+	int i, n, cv = 0, var = 0;
+	struct btf *btf;
+
+	btf = btf__parse("/sys/kernel/btf/vmlinux", NULL);
+	if (!btf) {
+		test__skip();
+		return;
+	}
+
+	skel = btf_show_void__open_and_load();
+	if (!ASSERT_OK_PTR(skel, "skel_open_and_load"))
+		goto out_btf;
+
+	n = btf__type_cnt(btf);
+	for (i = 1; i < n && !(cv && var); i++) {
+		t = btf__type_by_id(btf, i);
+		if (!cv && btf_kind(t) == BTF_KIND_CONST && t->type == 0)
+			cv = i;
+		/* Pick a VAR small enough to render from the program's buffer. */
+		if (!var && btf_kind(t) == BTF_KIND_VAR) {
+			long sz = btf__resolve_size(btf, t->type);
+
+			if (sz > 0 && sz <= (long)sizeof(skel->bss->obj))
+				var = i;
+		}
+	}
+
+	/* "const void" renders the "<unsupported kind:0>" placeholder. */
+	if (test__start_subtest("const_void")) {
+		if (cv) {
+			ASSERT_EQ(run(skel, cv),
+				  sizeof("<unsupported kind:0>") - 1, "ret");
+			ASSERT_STREQ(skel->bss->out, "<unsupported kind:0>",
+				     "placeholder");
+		} else {
+			test__skip();
+		}
+	}
+
+	/* A BTF_KIND_VAR must resolve and render without error. */
+	if (test__start_subtest("var")) {
+		if (var)
+			ASSERT_GT(run(skel, var), 0, "ret");
+		else
+			test__skip();
+	}
+
+	btf_show_void__destroy(skel);
+out_btf:
+	btf__free(btf);
+}
diff --git a/tools/testing/selftests/bpf/progs/btf_show_void.c b/tools/testing/selftests/bpf/progs/btf_show_void.c
new file mode 100644
index 000000000000..44af80fbbb80
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/btf_show_void.c
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "btf_ptr.h"
+#include <bpf/bpf_helpers.h>
+
+__u32 type_id;
+/* A buffer we own to render the selected type from, kept in bounds. */
+char obj[256];
+char out[64];
+long ret;
+
+SEC("raw_tp/sys_enter")
+int dump_type(void *ctx)
+{
+	struct btf_ptr ptr = {
+		.ptr = obj,
+		.type_id = type_id,
+		.flags = 0,
+	};
+
+	ret = bpf_snprintf_btf(out, sizeof(out), &ptr, sizeof(ptr), 0);
+	return 0;
+}
+
+char _license[] SEC("license") = "GPL";
-- 
2.43.0