Linux kernel BPF verifier: pointer comparison wrongly infers non-null, allowing a missed NULL deref

CVSS 5.5CVE-2026-98134Kernel, userspace & hypervisorcurated

Impact

When a BPF program compares two pointers, the verifier stripped PTR_MAYBE_NULL based only on the absence of that flag on the other operand. For types such as PTR_TO_MEM | PTR_UNTRUSTED, which can legitimately be NULL at runtime, that inference is wrong, so the verifier accepts a program containing a NULL pointer dereference and the kernel faults when it runs. The record scores this as availability impact only. A kernel oops on a GPU node is a whole-node event: co-tenant GPU pods die with it and the node needs a drain and reboot, which is expensive on a box holding long-running training jobs. Exposure is bounded by who may load BPF programs - on a host with unprivileged BPF disabled, only the node agent, CNI and tracing tooling can reach this path.

Who can reach it

Local, authenticated: requires the ability to load a BPF program (CAP_BPF/CAP_SYS_ADMIN, or unprivileged BPF enabled). No network path.

What to do

Pick up the fix (commits b55c9f019e16 and d3ef6c097ba0, replacing type_may_be_null() with reg_not_null() in check_cond_jmp_op()) through your distribution kernel, then drain and reboot each node. Until then, confirm kernel.unprivileged_bpf_disabled=1 and that tenant pods do not hold CAP_BPF. No fixed release version is named in the record.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-98134 https://git.kernel.org/stable/c/b55c9f019e169ed0d01394f96e172286a8b21b99 https://git.kernel.org/stable/c/d3ef6c097ba078e1f8c7239d76a0ce8b61e75095

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.