bpf: check_cond_jmp_op(): properly infer if register is null
In the Linux kernel, the following vulnerability has been resolved: bpf: check_cond_jmp_op(): 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 PTR_MAYBE_NULL flag, but which allows a value to be NULL at runtime. Here is an example: // `a` is PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED // `a` is 0 at runtime. // `b` is PTR_TO_MAP_VALUE | PTR_MAYBE_NULL void *a = bpf_rdonly_cast(0, 0); int *b = bpf_map_lookup_elem(...); if (a == b) *b = 42; // verifier does not catch null pointer dereference This happens because of a special case in check_cond_jmp_op(), which attempts to strip PTR_MAYBE_NULL 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 PTR_MAYBE_NULL flag on rA's or rB's type. But that is not sufficient for types like PTR_TO_MEM, as in the example. This patch replaces type_may_be_null() call with reg_not_null(), which contains an allowlist of types for which absence of PTR_MAYBE_NULL actually means that the value can't be NULL at runtime. At the moment, the list in the reg_not_null() omits two types for which PTR_MAYBE_NULL is applicable: PTR_TO_XDP_SOCK and PTR_TO_BUF. In order to remain backward compatible, and assuming that only comparison between pointers of the same type makes sense, this commit extends re
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.12.114, 6.18.57, 6.6.160, 7.2.7
- CVEs
- CVE-2026-98134
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 2 Nov 2026, 20:14 UTC · Revision 1
Source evidence
bpf: check_cond_jmp_op(): properly infer if register is null
core-osv · Original sourcePublished 25 Sept 2026, 10:36 UTC
In the Linux kernel, the following vulnerability has been resolved: bpf: check_cond_jmp_op(): 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 PTR_MAYBE_NULL flag, but which allows a value to be NULL at runtime. Here is an example: // `a` is PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED // `a` is 0 at runtime. // `b` is PTR_TO_MAP_VALUE | PTR_MAYBE_NULL void *a = bpf_rdonly_cast(0, 0); int *b = bpf_map_lookup_elem(...); if (a == b) *b = 42; // verifier does not catch null pointer dereference This happens because of a special case in check_cond_jmp_op(), which attempts to strip PTR_MAYBE_NULL 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 PTR_MAYBE_NULL flag on rA's or rB's type. But that is not sufficient for types like PTR_TO_MEM, as in the example. This patch replaces type_may_be_null() call with reg_not_null(), which contains an allowlist of types for which absence of PTR_MAYBE_NULL actually means that the value can't be NULL at runtime. At the moment, the list in the reg_not_null() omits two types for which PTR_MAYBE_NULL is applicable: PTR_TO_XDP_SOCK and PTR_TO_BUF. In order to remain backward compatible, and assuming that only comparison between pointers of the same type makes sense, this commit extends re
osv:CVE-2026-98134
Kernel
Fixed versions: 6.6.160, 6.12.114, 6.18.57, 7.2.7
Complete source record
{
"id": "811a0a4fabcf590624e5d880b97cd21b6f743615b2ed5c55181a2aa4d20af3a3",
"url": "https://osv.dev/vulnerability/CVE-2026-98134",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "bpf: check_cond_jmp_op(): properly infer if register is null",
"summary": "In the Linux kernel, the following vulnerability has been resolved: bpf: check_cond_jmp_op(): 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 PTR_MAYBE_NULL flag, but which allows a value to be NULL at runtime. Here is an example: // `a` is PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED // `a` is 0 at runtime. // `b` is PTR_TO_MAP_VALUE | PTR_MAYBE_NULL void *a = bpf_rdonly_cast(0, 0); int *b = bpf_map_lookup_elem(...); if (a == b) *b = 42; // verifier does not catch null pointer dereference This happens because of a special case in check_cond_jmp_op(), which attempts to strip PTR_MAYBE_NULL 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 PTR_MAYBE_NULL flag on rA's or rB's type. But that is not sufficient for types like PTR_TO_MEM, as in the example. This patch replaces type_may_be_null() call with reg_not_null(), which contains an allowlist of types for which absence of PTR_MAYBE_NULL actually means that the value can't be NULL at runtime. At the moment, the list in the reg_not_null() omits two types for which PTR_MAYBE_NULL is applicable: PTR_TO_XDP_SOCK and PTR_TO_BUF. In order to remain backward compatible, and assuming that only comparison between pointers of the same type makes sense, this commit extends re",
"evidence": "osv:CVE-2026-98134",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.6.160",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.114",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.57",
"evidence": "/affected/1/ranges"
},
{
"value": "7.2.7",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-98134",
"aliases": [
"CVE-2026-98134"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "befae75856ab406a3f3fab2aa2118cf3b2dfe3e6"
},
{
"fixed": "d51cd486930f5bcfd4b55d55ab8e47b03f93d2ed"
},
{
"fixed": "dfd8f8adda565e08c370c45cf9d6b2511ba9b5c6"
},
{
"fixed": "9bf96b4347f541604b3caadeabda0773d9ceaf2a"
},
{
"fixed": "b55c9f019e169ed0d01394f96e172286a8b21b99"
},
{
"fixed": "d3ef6c097ba078e1f8c7239d76a0ce8b61e75095"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-98134.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.160"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.114"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.57"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.2.7"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-98134.json"
}
}
],
"modified": "2026-10-28T02:30:23.058196288Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/9bf96b4347f541604b3caadeabda0773d9ceaf2a",
"https://git.kernel.org/stable/c/b55c9f019e169ed0d01394f96e172286a8b21b99",
"https://git.kernel.org/stable/c/d3ef6c097ba078e1f8c7239d76a0ce8b61e75095",
"https://git.kernel.org/stable/c/d51cd486930f5bcfd4b55d55ab8e47b03f93d2ed",
"https://git.kernel.org/stable/c/dfd8f8adda565e08c370c45cf9d6b2511ba9b5c6",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/98xxx/CVE-2026-98134.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-98134",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/98xxx/CVE-2026-98134.json"
}
},
"related_cves": [
{
"value": "CVE-2026-98134",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 489684,
"published_at": "2026-09-25T10:36:12.919+00:00"
}