CVE-2026-98065 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject key-less BTF for hash maps
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:
RIP: 0010:btf_type_show+0x223/0x2e0 kernel/bpf/btf.c:8232 RSP: 0018:ffffc9000399f868 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000005 RSI: 0000000000000000 RDI: 0000000000000028 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: ffffc9000399f970 R11: 0000000000000001 R12: ffffffff9b96b140 R13: ffffc9000399f8e0 R14: ffff88803d393c00 R15: 0000000000000003 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000000 CR3: 000000003d213000 CR4: 0000000000352ef0 DR0: 0000000039ae8f55 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 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 traverse.part.0.constprop.0+0x107/0x650 fs/seq_file.c:112 traverse fs/seq_file.c:99 [inline]
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 ksys_pread64 fs/read_write.c:764 [inline]
__do_sys_pread64 fs/read_write.c:772 [inline]
__se_sys_pread64 fs/read_write.c:769 [inline]
__x64_sys_pread64+0x1eb/0x250 fs/read_write.c:769 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Reject a key-less BTF in htab_map_check_btf() and rhtab_map_check_btf(), restoring the previous behavior.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel contains a vulnerability within its Berkeley Packet Filter (BPF) subsystem, specifically affecting hash map implementations that utilize Bpf Type Format (BTF). The core issue stems from an inconsistency in how key-less BTF definitions are validated for different map types. Historically, the function map_check_btf() enforced strict validation by rejecting any map configuration where the btf_key_type_id was zero, unless a specific callback routine existed to handle such edge cases. Hash maps previously lacked this callback mechanism and therefore correctly rejected invalid configurations at creation time. However recent updates introduced callbacks for hash tables (htab) and resizable hash tables (rhtab) primarily to manage destructor logic for special fields rather than to validate structural integrity regarding keys. These new callbacks do not inspect the key type identifier, allowing a map with no defined key to pass validation checks during initialization. This oversight permits the creation of malformed BPF maps that violate fundamental data structure assumptions required by subsequent operations.
The operational impact manifests when an unprivileged user or compromised process attempts to interact with these improperly configured hash maps through the bpf filesystem interface. When reading back map metadata via bpffs, the kernel invokes functions such as btf_type_seq_show() and subsequently btf_type_by_id(). In this specific scenario involving a key-less map, the system retrieves the void type which corresponds to a null pointer in the kind_ops array for BTF_KIND_UNKN. The function btf_type_show() then attempts to dereference this NULL pointer while processing the sequence data. This action triggers an invalid memory access resulting in a kernel panic or crash as evidenced by the instruction pointer referencing btf_type_show within kernel/bpf/btf.c. Such a vulnerability allows for local denial of service attacks where any user with appropriate permissions to create BPF maps can destabilize the entire system simply by triggering this code path through standard file read operations on the exposed map objects.
From a classification perspective, this flaw aligns with CWE-476 which denotes NULL Pointer Dereference vulnerabilities arising from improper validation of input parameters before use. The attack vector is categorized under ATT&CK technique T1059 as Command and Scripting Interpreter abuse within the context of local privilege escalation or system disruption via kernel exploitation techniques. Although the immediate effect observed is a crash, such memory corruption bugs often serve as precursors to more severe exploits if additional conditions are met in different contexts. The root cause lies in the decoupling of validation logic from functional callbacks during recent refactoring efforts aimed at supporting dynamic field management in resizable hash tables.
The resolution involves modifying htab_map_check_btf() and rhtab_map_check_btf() to explicitly reject configurations where btf_key_type_id equals zero. This change restores the previous secure behavior by ensuring that all BPF map types adhere to consistent validation standards regardless of whether they possess additional destructor callbacks. By enforcing this constraint at the point of map creation, the kernel prevents the allocation and exposure of malformed objects that could lead to subsequent NULL pointer dereferences during metadata retrieval operations. System administrators should apply the corresponding kernel patch or update their distribution packages to mitigate this risk. Continuous monitoring for unusual BPF program loads and strict enforcement of least privilege principles regarding eBPF capabilities remain recommended defensive measures alongside timely patching.