Vulnerability-Lookup

GHSA-4GCP-C78X-X35M

Vulnerability from github – Published: 2026-09-17 18:32 – Updated: 2026-09-18 18:31

Details

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

bpf: Check load-acquire src ptr type before the load

check_atomic_load() calls check_load_mem() before atomic_ptr_type_ok(). For a load-acquire that fetches into its own source register (dst_reg == src_reg), check_load_mem() overwrites src_reg's type with the type of the loaded value, so the subsequent atomic_ptr_type_ok() no longer sees the source pointer and fails to reject the disallowed types (ctx, pkt, flow_keys, sock).

Since bpf_convert_ctx_accesses() does not rewrite atomic loads, the raw access to the underlying kernel object is left in place. The destination type is taken from the ctx access itself, so a load-acquire of the sk field of struct __sk_buff for example leaves the register typed as PTR_TO_SOCK_COMMON_OR_NULL, which type_is_sk_pointer() does not match either, while it actually holds unconverted struct sk_buff bytes. Once the NULL check has passed this is a type confusion, not just a leak of kernel data.

Validate src_reg with check_reg_arg() and check the source pointer type with atomic_ptr_type_ok() before the load again, mirroring check_atomic_rmw(). Out-of-range register numbers are already rejected earlier by check_and_resolve_insns() (commit 503d21ef8eac ("bpf: Do register range validation early")), and the only exemption there, is_stack_arg_ldx(), requires BPF_LDX | BPF_MEM | BPF_DW and thus never matches a BPF_ATOMIC insn. atomic_ptr_type_ok() can therefore not dereference register state out of bounds, that is, the out-of-bounds read addressed by the Fixes commit below does not reappear (as proven also via selftest).

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-90312"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-17T17:17:28Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Check load-acquire src ptr type before the load\n\ncheck_atomic_load() calls check_load_mem() before atomic_ptr_type_ok().\nFor a load-acquire that fetches into its own source register (dst_reg ==\nsrc_reg), check_load_mem() overwrites src_reg\u0027s type with the type of the\nloaded value, so the subsequent atomic_ptr_type_ok() no longer sees the\nsource pointer and fails to reject the disallowed types (ctx, pkt,\nflow_keys, sock).\n\nSince bpf_convert_ctx_accesses() does not rewrite atomic loads, the raw\naccess to the underlying kernel object is left in place. The destination\ntype is taken from the ctx access itself, so a load-acquire of the sk\nfield of struct __sk_buff for example leaves the register typed as\nPTR_TO_SOCK_COMMON_OR_NULL, which type_is_sk_pointer() does not match\neither, while it actually holds unconverted struct sk_buff bytes. Once\nthe NULL check has passed this is a type confusion, not just a leak of\nkernel data.\n\nValidate src_reg with check_reg_arg() and check the source pointer type\nwith atomic_ptr_type_ok() before the load again, mirroring\ncheck_atomic_rmw(). Out-of-range register numbers are already rejected\nearlier by check_and_resolve_insns() (commit 503d21ef8eac (\"bpf: Do\nregister range validation early\")), and the only exemption there,\nis_stack_arg_ldx(), requires BPF_LDX | BPF_MEM | BPF_DW and thus never\nmatches a BPF_ATOMIC insn. atomic_ptr_type_ok() can therefore not\ndereference register state out of bounds, that is, the out-of-bounds\nread addressed by the Fixes commit below does not reappear (as proven\nalso via selftest).",
  "id": "GHSA-4gcp-c78x-x35m",
  "modified": "2026-09-18T18:31:29Z",
  "published": "2026-09-17T18:32:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90312"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/422a416041172af1ac610736d5f556d22b31b115"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6ee7b00888498cf387dd30729e18a05328b94709"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b87803391baa7e0bef60549d8841f12e549ad057"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CVE-2026-90312 (GCVE-0-2026-90312)

Vulnerability from cvelistv5 – Published: 2026-09-17 16:08 – Updated: 2026-10-19 09:01

Title

bpf: Check load-acquire src ptr type before the load

Summary

In the Linux kernel, the following vulnerability has been resolved: bpf: Check load-acquire src ptr type before the load check_atomic_load() calls check_load_mem() before atomic_ptr_type_ok(). For a load-acquire that fetches into its own source register (dst_reg == src_reg), check_load_mem() overwrites src_reg's type with the type of the loaded value, so the subsequent atomic_ptr_type_ok() no longer sees the source pointer and fails to reject the disallowed types (ctx, pkt, flow_keys, sock). Since bpf_convert_ctx_accesses() does not rewrite atomic loads, the raw access to the underlying kernel object is left in place. The destination type is taken from the ctx access itself, so a load-acquire of the sk field of struct __sk_buff for example leaves the register typed as PTR_TO_SOCK_COMMON_OR_NULL, which type_is_sk_pointer() does not match either, while it actually holds unconverted struct sk_buff bytes. Once the NULL check has passed this is a type confusion, not just a leak of kernel data. Validate src_reg with check_reg_arg() and check the source pointer type with atomic_ptr_type_ok() before the load again, mirroring check_atomic_rmw(). Out-of-range register numbers are already rejected earlier by check_and_resolve_insns() (commit 503d21ef8eac ("bpf: Do register range validation early")), and the only exemption there, is_stack_arg_ldx(), requires BPF_LDX | BPF_MEM | BPF_DW and thus never matches a BPF_ATOMIC insn. atomic_ptr_type_ok() can therefore not dereference register state out of bounds, that is, the out-of-bounds read addressed by the Fixes commit below does not reappear (as proven also via selftest).

Severity

7.8 (High)


                        
                          CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Assigner

Linux CNA under the mitre root

CNA scorecard D 53/100 over 6639 records in the last 180 days details

References

3 references

URL	Tags
https://git.kernel.org/stable/c/6ee7b00888498cf38…
https://git.kernel.org/stable/c/422a416041172af1a…
https://git.kernel.org/stable/c/b87803391baa7e0be…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: c03bb2fa327e4c25d6c5360a8803a4b1cdc2d0b9 , < 6ee7b00888498cf387dd30729e18a05328b94709 (git) Affected: c03bb2fa327e4c25d6c5360a8803a4b1cdc2d0b9 , < 422a416041172af1ac610736d5f556d22b31b115 (git) Affected: c03bb2fa327e4c25d6c5360a8803a4b1cdc2d0b9 , < b87803391baa7e0bef60549d8841f12e549ad057 (git)
Linux	Linux	Affected: 6.15 Unaffected: 0 , < 6.15 (semver) Unaffected: 6.18.52 , ≤ 6.18.* (semver) Unaffected: 7.2.6 , ≤ 7.2.* (semver) Unaffected: 7.3 , ≤ * (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": "6ee7b00888498cf387dd30729e18a05328b94709",
              "status": "affected",
              "version": "c03bb2fa327e4c25d6c5360a8803a4b1cdc2d0b9",
              "versionType": "git"
            },
            {
              "lessThan": "422a416041172af1ac610736d5f556d22b31b115",
              "status": "affected",
              "version": "c03bb2fa327e4c25d6c5360a8803a4b1cdc2d0b9",
              "versionType": "git"
            },
            {
              "lessThan": "b87803391baa7e0bef60549d8841f12e549ad057",
              "status": "affected",
              "version": "c03bb2fa327e4c25d6c5360a8803a4b1cdc2d0b9",
              "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.15"
            },
            {
              "lessThan": "6.15",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.52",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.6",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.52",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.6",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Check load-acquire src ptr type before the load\n\ncheck_atomic_load() calls check_load_mem() before atomic_ptr_type_ok().\nFor a load-acquire that fetches into its own source register (dst_reg ==\nsrc_reg), check_load_mem() overwrites src_reg\u0027s type with the type of the\nloaded value, so the subsequent atomic_ptr_type_ok() no longer sees the\nsource pointer and fails to reject the disallowed types (ctx, pkt,\nflow_keys, sock).\n\nSince bpf_convert_ctx_accesses() does not rewrite atomic loads, the raw\naccess to the underlying kernel object is left in place. The destination\ntype is taken from the ctx access itself, so a load-acquire of the sk\nfield of struct __sk_buff for example leaves the register typed as\nPTR_TO_SOCK_COMMON_OR_NULL, which type_is_sk_pointer() does not match\neither, while it actually holds unconverted struct sk_buff bytes. Once\nthe NULL check has passed this is a type confusion, not just a leak of\nkernel data.\n\nValidate src_reg with check_reg_arg() and check the source pointer type\nwith atomic_ptr_type_ok() before the load again, mirroring\ncheck_atomic_rmw(). Out-of-range register numbers are already rejected\nearlier by check_and_resolve_insns() (commit 503d21ef8eac (\"bpf: Do\nregister range validation early\")), and the only exemption there,\nis_stack_arg_ldx(), requires BPF_LDX | BPF_MEM | BPF_DW and thus never\nmatches a BPF_ATOMIC insn. atomic_ptr_type_ok() can therefore not\ndereference register state out of bounds, that is, the out-of-bounds\nread addressed by the Fixes commit below does not reappear (as proven\nalso via selftest)."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The attacker-controlled input is a BPF_LOAD_ACQ insn with dst_reg==src_reg in the bytecode bpf_prog_load() copies from bpf(2) BPF_PROG_LOAD (__sys_bpf). do_check_insn()\u2192check_atomic()\u2192check_atomic_load() then lets check_load_mem() overwrite the source type before atomic_ptr_type_ok(); no remote protocol message carries that insn.\nAC:L - The attacker authors a SOCKET_FILTER program that does BPF_LOAD_ACQ of offsetof(__sk_buff, sk) with dst_reg==src_reg (the PTR_TO_CTX). check_load_mem() replaces that register with PTR_TO_SOCK_COMMON_OR_NULL, so type_is_sk_pointer() does not match and atomic_ptr_type_ok() accepts it. No race or uninfluenced layout is required.\nPR:L - bpf_prog_load() allows BPF_PROG_TYPE_SOCKET_FILTER and BPF_PROG_TYPE_CGROUP_SKB without CAP_BPF when sysctl_unprivileged_bpf_disabled is 0; otherwise bpf_token_capable(CAP_BPF) is enough. bpf_token_capable() uses ns_capable() on a delegated token userns, not init-namespace root. verifier_load_acquire.c marks socket load-acquire __success_unpriv.\nUI:N - The attacker loads the program with BPF_PROG_LOAD and runs it via BPF_PROG_TEST_RUN (bpf_prog_test_run_skb on sk_filter_prog_ops) or attaches it to their own socket with setsockopt(SO_ATTACH_BPF)\u2192sk_attach_bpf() and triggers the filter. No other user must mount or open a file.\nS:U - check_atomic_load()\u0027s type confusion and the later interpreter/JIT smp_load_acquire plus bpf_sock_convert_ctx_access loads run in the host kernel that accepted the program. That is in-kernel privilege escalation, not a KVM/Xen guest-to-host escape or IOMMU bypass.\nC:H - bpf_convert_ctx_accesses() does not rewrite BPF_ATOMIC, so load-acquire of offsetof(__sk_buff, sk) reads unconverted sk_buff bytes while the register is typed PTR_TO_SOCK_COMMON_OR_NULL. After a NULL check, later LDX of bpf_sock fields is rewritten by bpf_sock_convert_ctx_access() into struct sock loads against that pointer.\nI:H - The same confused PTR_TO_SOCK_COMMON is accepted as ARG_PTR_TO_SOCK_COMMON by bpf_sk_fullsock and, on CGROUP_SKB, bpf_sk_storage_get, which dereference and update sock-shaped kernel state on an object that is actually raw sk_buff memory. Commit-described verifier type confusion, not a bounded scalar leak.\nA:H - Interpreter BPF_LOAD_ACQ does smp_load_acquire of the unconverted ctx address, and follow-on bpf_sock_convert_ctx_access LDXes dereference that value as struct sock. A non-pointer or unmapped value page-faults in kernel context; the attacker can repeat this via BPF_PROG_TEST_RUN or the attached filter."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-19T09:01:28.834Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/6ee7b00888498cf387dd30729e18a05328b94709"
        },
        {
          "url": "https://git.kernel.org/stable/c/422a416041172af1ac610736d5f556d22b31b115"
        },
        {
          "url": "https://git.kernel.org/stable/c/b87803391baa7e0bef60549d8841f12e549ad057"
        }
      ],
      "title": "bpf: Check load-acquire src ptr type before the load",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-90312",
    "datePublished": "2026-09-17T16:08:32.287Z",
    "dateReserved": "2026-09-11T19:38:34.801Z",
    "dateUpdated": "2026-10-19T09:01:28.834Z",
    "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.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

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