CVE-2026-98134: bpf: check_cond_jmp_op(): properly infer if register is null

In the Linux kernel, the following vulnerability has been resolved:

bpf: checkcondjmpop(): properly infer if register is null

Nicholas Carlini reported a bug when verifier can incorrectly infer that a pointer is non-null. The bug occurs when two pointers are compared and one of them has a type w/o PTRMAYBENULL flag, but which allows a value to be NULL at runtime. Here is an example:

// a is PTRTOMEM | MEMRDONLY | PTRUNTRUSTED // a is 0 at runtime. // b is PTRTOMAPVALUE | PTRMAYBENULL void a = bpfrdonlycast(0, 0); int b = bpfmaplookupelem(...);

if (a == b) b = 42; // verifier does not catch null pointer dereference

This happens because of a special case in checkcondjmpop(), which attempts to strip PTRMAYBENULL flags from pointer types, when processing comparisons like rA == rB, if either rA or rB can't be null.

The non-null property is derived based on the absence of PTRMAYBENULL flag on rA's or rB's type. But that is not sufficient for types like PTRTOMEM, as in the example.

This patch replaces typemaybenull() call with regnotnull(), which contains an allowlist of types for which absence of PTRMAYBENULL actually means that the value can't be NULL at runtime.

At the moment, the list in the regnotnull() omits two types for which PTRMAYBENULL is applicable: PTRTOXDPSOCK and PTRTOBUF. In order to remain backward compatible, and assuming that only comparison between pointers of the same type makes sense, this commit extends regnotnull(). W/o such an extension e.g. verifierjeqinfernotnull/nullptrtomapvalue fails.

regnotnull() can be extended further, but I deem that out of scope for the fix at hand. Explicit basetype(...) != PTRTOBTFID checks in the checkcondjmpop() can be removed with migration to regnotnull(), but that is a behavioural change, as the special case would start matching for PTRTOBTFID that is also istrustedreg(). I omit the behavioural change from this commit.