CVE-2026-98064: bpf: Fix NULL-ptr-deref when showing a void BTF type
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix NULL-ptr-deref when showing a void BTF type
btfmodifiershow() resolves the modifier and then calls btftypeops(t)->show() unconditionally. For the void type (typeid 0, BTFKINDUNKN) kindops[] has no entry, so ->show is NULL.
A "const void" (a modifier resolving to void) cannot be a map key or value - mapcheckbtf() rejects it because void has no size - so the map dump path does not reach it. But bpfsnprintfbtf() takes a typeid straight from the BPF program, and passing such a "const void" from the vmlinux BTF NULL-derefs:
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:btfmodifiershow (kernel/bpf/btf.c:2914) Call Trace: <TASK> btftypeshow (kernel/bpf/btf.c:8251) btftypesnprintfshow (kernel/bpf/btf.c:8321) bpfsnprintfbtf (kernel/trace/bpftrace.c:1047) bpfprogtestrunrawtp (net/bpf/testrun.c:829) sysbpf (kernel/bpf/syscall.c:4804) dosyscall64 (arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121) </TASK>
Fall back to btfdfshow() when the resolved type has no show op; it emits the "<unsupported kind:N>" placeholder already used for kinds like FWD and FUNC. bpfsnprintfbtf() then returns the length as usual.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In btf_modifier_show(), fall back to btf_df_show() when the resolved BTF type has no show operation; for a void type, emit the existing "<unsupported kind:N>" placeholder instead of dereferencing a NULL show function.
Event History
Frequently Asked Questions
What input is needed to trigger the crash?
A BPF program must pass a type ID for a modifier that resolves to void, such as "const void", to bpf_snprintf_btf(). The vulnerable code then attempts to call a missing show operation for BTF_KIND_UNKN.
Are BPF map operations affected by this condition?
No. A "const void" type cannot be used as a map key or value because map_check_btf() rejects void types due to their lack of size, so the map dump path does not reach the vulnerable operation.
How can an existing occurrence be identified?
The reported failure is a KASAN null-pointer dereference in btf_modifier_show(), with btf_type_show(), btf_type_snprintf_show(), and bpf_snprintf_btf() in the call trace. The provided example reaches it through bpf_prog_test_run_raw_tp() and the bpf syscall.