bpf: Fix NULL-ptr-derefs when showing a void BTF type

Quoted 14 lines

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:

Quoted 14 lines

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 ([email protected]) 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]

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 [email protected]

Closes https://lore.kernel.org/all/[email protected]/T/ open here

Signed-off-by Jiayuan Chen <[email protected]>

---
 kernel/bpf/hashtab.c | 8 ++++++++
 1 file changed, 8 insertions(+)

kernel/bpf/hashtab.c +0 -0

index d40cb5dd446c..43123424183c 100644

kernel/bpf/hashtab.c +7 -0

+	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);
 }
 

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] btf_var_show() unconditionally dereferences btf_type_ops(t) which can be NULL if a VAR resolves to the void type. --

commit e40701f4e16b364aff9e3327fa4cdff79bc39336
Author: Jiayuan Chen <[email protected]>

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.

Quoted 20 lines

kernel/bpf/btf.c +9 -1

index da36d4b9d31ab..81506cbb9f9ae 100644
@@ -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);
  }
 

kernel/bpf/btf.c static void btf_modifier_show(const struct btf *btf, · line 2925

Quoted 1 line

kernel/bpf/btf.c +0 -0

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

[Severity: High]
This isn't a bug introduced by this patch, but does btf_var_show() have the same problem where btf_type_ops(t) can be NULL if a VAR resolves to the void type?

Quoted 10 lines

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?

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 <[email protected]>

---
 kernel/bpf/btf.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

kernel/bpf/btf.c +0 -0

index 91b8ce77f699..6e267c4c4e1f 100644
@@ -2911,7 +2911,15 @@ static void btf_modifier_show(const struct btf *btf,
 	else
 		t = btf_type_skip_modifiers(btf, type_id, NULL);
 

kernel/bpf/btf.c +0 -0

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

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 <[email protected]>

---
 kernel/bpf/btf.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

kernel/bpf/btf.c +0 -0

index 6e267c4c4e1f..3cf35ee49c10 100644
@@ -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)
 {

kernel/bpf/btf.c +0 -0

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

Quoted 6 lines

tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c new file +0 -0

new file mode 100644
index 0000000000000..a7d037f57a7ef
@@ -0,0 +1,82 @@

[ ... ]

tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c line 35

Quoted 10 lines

tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c new file +10 -0

+	/*
+	 * 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.

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 <[email protected]>

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

tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c new file +44 -0

new file mode 100644
index 000000000000..a7d037f57a7e
@@ -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) {

tools/testing/selftests/bpf/prog_tests/btf_map_keyless.c new file +4 -0

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