GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF: a key-less BTF hash map can be created and reading it through bpffs NULL-derefs

UnscoredCVE-2026-98065Kernel, userspace & hypervisorcurated

Impact

map_check_btf() defers the key-less BTF decision to a map's ->map_check_btf callback. Hash maps used to have none, so btf_key_type_id == 0 was rejected outright; once htab and rhtab gained a callback to register a dtor, neither of which inspects the key, a key-less hash map began passing validation. Reading that map back through bpffs feeds key type_id 0 into btf_type_seq_show(), kind_ops[BTF_KIND_UNKN] is NULL, and btf_type_show() dereferences it - a kernel crash from a plain pread() on a bpffs file. On a GPU node that is an unplanned reboot and a lost job; reaching it needs BPF map creation privilege, so the exposure is through system agents, not tenant pods.

Who can reach it

Local, privileged: requires creating a BPF hash map with a key-less BTF (CAP_BPF/CAP_SYS_ADMIN) and then reading it via bpffs. Anyone able to read the pinned bpffs file can trigger the crash once such a map exists.

What to do

Update to a stable kernel that rejects a key-less BTF in htab_map_check_btf() and rhtab_map_check_btf(), restoring the previous behaviour. Requires a node reboot after drain. No separate mitigation beyond limiting who can create BPF maps and who can read bpffs mounts.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.