CVE-2026-98040: bpf: Mark the zero register precise for a register-form NULL check
In the Linux kernel, the following vulnerability has been resolved:
bpf: Mark the zero register precise for a register-form NULL check
checkcondjmpop() accepts "if rA <op> rB" as a NULL check for a nullable pointer rA when rB is a scalar known to be zero, lifts PTRMAYBENULL from rA in the corresponding branch and does not mark rB precise. Consider the following program:
r0 = bpfgetprandomu32(); r6 = 1; / the r6 == 0 path is explored first / if (r0 == 0) goto 1f; r6 = 0; 1: r0 = bpfmaplookupelem(map, &0); / absent, NULL at runtime / if (r0 == r6) goto 2f; / taken as a NULL check for r0 / (u8 )(r0 + 0); / verifier: map value; runtime: zero / 2: return 0;
The r6 == 0 path is explored first and the dereference is accepted. The r6 == 1 path is pruned at the checkpoint recorded for (1), so the comparison is never verified with a non-zero r6. At runtime a failed lookup returns NULL, NULL != 1 takes the non-NULL edge and the program dereferences a pointer that is zero.
Affected Software
Event History
Frequently Asked Questions
What runtime condition leads to the invalid pointer dereference?
A map lookup must fail and return NULL, while the scalar register used in the subsequent comparison has the value 1 at runtime. The comparison then takes the edge treated by the verifier as non-NULL, and the program dereferences the zero pointer.
Why can the verifier accept a program whose comparison register is non-zero on an executable path?
The verifier explores the path where the comparison register is zero first and records a checkpoint. The path where that register is 1 is then pruned at that checkpoint, so the comparison is not revalidated with the non-zero value.
What BPF code pattern is relevant when reviewing programs?
Review register-form comparisons between a nullable pointer returned by bpf_map_lookup_elem() and a scalar register, especially where the scalar can be zero on one verifier-explored path but non-zero at runtime on another. A failed lookup followed by dereference on the comparison's non-NULL edge is the unsafe pattern described.