Vulnerability-Lookup

GHSA-PP33-9GGX-8QJ6

Vulnerability from github – Published: 2026-09-25 12:31 – Updated: 2026-09-25 12:31

Details

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 reg_not_null(). W/o such an extension e.g. verifier_jeq_infer_not_null/null_ptr_to_map_value fails.

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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-98134"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-25T11:17:44Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: check_cond_jmp_op(): properly infer if register is null\n\nNicholas Carlini reported a bug when verifier can incorrectly infer\nthat a pointer is non-null. The bug occurs when two pointers are\ncompared and one of them has a type w/o PTR_MAYBE_NULL flag,\nbut which allows a value to be NULL at runtime.\nHere is an example:\n\n  // `a` is PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED\n  // `a` is 0 at runtime.\n  // `b` is PTR_TO_MAP_VALUE | PTR_MAYBE_NULL\n  void *a = bpf_rdonly_cast(0, 0);\n  int  *b = bpf_map_lookup_elem(...);\n\n  if (a == b)\n    *b = 42;  // verifier does not catch null pointer dereference\n\nThis happens because of a special case in check_cond_jmp_op(),\nwhich attempts to strip PTR_MAYBE_NULL flags from pointer types,\nwhen processing comparisons like `rA == rB`, if either rA or rB can\u0027t\nbe null.\n\nThe non-null property is derived based on the absence of\nPTR_MAYBE_NULL flag on rA\u0027s or rB\u0027s type. But that is not sufficient\nfor types like PTR_TO_MEM, as in the example.\n\nThis patch replaces type_may_be_null() call with reg_not_null(),\nwhich contains an allowlist of types for which absence of\nPTR_MAYBE_NULL actually means that the value can\u0027t be NULL at runtime.\n\nAt the moment, the list in the reg_not_null() omits two types for\nwhich PTR_MAYBE_NULL is applicable: PTR_TO_XDP_SOCK and PTR_TO_BUF.\nIn order to remain backward compatible, and assuming that only\ncomparison between pointers of the same type makes sense,\nthis commit extends reg_not_null(). W/o such an extension e.g.\nverifier_jeq_infer_not_null/null_ptr_to_map_value fails.\n\nreg_not_null() can be extended further, but I deem that out of scope\nfor the fix at hand. Explicit base_type(...) != PTR_TO_BTF_ID\nchecks in the check_cond_jmp_op() can be removed with migration to\nreg_not_null(), but that is a behavioural change, as the special case\nwould start matching for PTR_TO_BTF_ID that is also is_trusted_reg().\nI omit the behavioural change from this commit.",
  "id": "GHSA-pp33-9ggx-8qj6",
  "modified": "2026-09-25T12:31:37Z",
  "published": "2026-09-25T12:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98134"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b55c9f019e169ed0d01394f96e172286a8b21b99"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d3ef6c097ba078e1f8c7239d76a0ce8b61e75095"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

CVE-2026-98134 (GCVE-0-2026-98134)

Vulnerability from cvelistv5 – Published: 2026-09-25 10:36 – Updated: 2026-09-25 10:36

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 reg_not_null(). W/o such an extension e.g. verifier_jeq_infer_not_null/null_ptr_to_map_value fails. reg_not_null() can be extended further, but I deem that out of scope for the fix at hand. Explicit base_type(...) != PTR_TO_BTF_ID checks in the check_cond_jmp_op() can be removed with migration to reg_not_null(), but that is a behavioural change, as the special case would start matching for PTR_TO_BTF_ID that is also is_trusted_reg(). I omit the behavioural change from this commit.

Severity

No CVSS data available.

Assigner

Linux mitre root

References

2 references

URL	Tags
https://git.kernel.org/stable/c/b55c9f019e169ed0d…
https://git.kernel.org/stable/c/d3ef6c097ba078e1f…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: befae75856ab406a3f3fab2aa2118cf3b2dfe3e6 , < b55c9f019e169ed0d01394f96e172286a8b21b99 (git) Affected: befae75856ab406a3f3fab2aa2118cf3b2dfe3e6 , < d3ef6c097ba078e1f8c7239d76a0ce8b61e75095 (git)
Linux	Linux	Affected: 6.2 Unaffected: 0 , < 6.2 (semver) Unaffected: 7.2.7 , ≤ 7.2.* (semver) Unaffected: 7.3-rc2 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/verifier.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "b55c9f019e169ed0d01394f96e172286a8b21b99",
              "status": "affected",
              "version": "befae75856ab406a3f3fab2aa2118cf3b2dfe3e6",
              "versionType": "git"
            },
            {
              "lessThan": "d3ef6c097ba078e1f8c7239d76a0ce8b61e75095",
              "status": "affected",
              "version": "befae75856ab406a3f3fab2aa2118cf3b2dfe3e6",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/verifier.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.2"
            },
            {
              "lessThan": "6.2",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.7",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3-rc2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.7",
                  "versionStartIncluding": "6.2",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3-rc2",
                  "versionStartIncluding": "6.2",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: check_cond_jmp_op(): properly infer if register is null\n\nNicholas Carlini reported a bug when verifier can incorrectly infer\nthat a pointer is non-null. The bug occurs when two pointers are\ncompared and one of them has a type w/o PTR_MAYBE_NULL flag,\nbut which allows a value to be NULL at runtime.\nHere is an example:\n\n  // `a` is PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED\n  // `a` is 0 at runtime.\n  // `b` is PTR_TO_MAP_VALUE | PTR_MAYBE_NULL\n  void *a = bpf_rdonly_cast(0, 0);\n  int  *b = bpf_map_lookup_elem(...);\n\n  if (a == b)\n    *b = 42;  // verifier does not catch null pointer dereference\n\nThis happens because of a special case in check_cond_jmp_op(),\nwhich attempts to strip PTR_MAYBE_NULL flags from pointer types,\nwhen processing comparisons like `rA == rB`, if either rA or rB can\u0027t\nbe null.\n\nThe non-null property is derived based on the absence of\nPTR_MAYBE_NULL flag on rA\u0027s or rB\u0027s type. But that is not sufficient\nfor types like PTR_TO_MEM, as in the example.\n\nThis patch replaces type_may_be_null() call with reg_not_null(),\nwhich contains an allowlist of types for which absence of\nPTR_MAYBE_NULL actually means that the value can\u0027t be NULL at runtime.\n\nAt the moment, the list in the reg_not_null() omits two types for\nwhich PTR_MAYBE_NULL is applicable: PTR_TO_XDP_SOCK and PTR_TO_BUF.\nIn order to remain backward compatible, and assuming that only\ncomparison between pointers of the same type makes sense,\nthis commit extends reg_not_null(). W/o such an extension e.g.\nverifier_jeq_infer_not_null/null_ptr_to_map_value fails.\n\nreg_not_null() can be extended further, but I deem that out of scope\nfor the fix at hand. Explicit base_type(...) != PTR_TO_BTF_ID\nchecks in the check_cond_jmp_op() can be removed with migration to\nreg_not_null(), but that is a behavioural change, as the special case\nwould start matching for PTR_TO_BTF_ID that is also is_trusted_reg().\nI omit the behavioural change from this commit."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-25T10:36:12.919Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/b55c9f019e169ed0d01394f96e172286a8b21b99"
        },
        {
          "url": "https://git.kernel.org/stable/c/d3ef6c097ba078e1f8c7239d76a0ce8b61e75095"
        }
      ],
      "title": "bpf: check_cond_jmp_op(): properly infer if register is null",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-98134",
    "datePublished": "2026-09-25T10:36:12.919Z",
    "dateReserved": "2026-09-25T10:25:14.319Z",
    "dateUpdated": "2026-09-25T10:36:12.919Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-PP33-9GGX-8QJ6

CVE-2026-98134 (GCVE-0-2026-98134)

Tags

Sightings

Nomenclature

Related by attack behaviour