Vulnerability-Lookup

GHSA-VX2X-82WW-5R7R

Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-13 09:32

Details

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

bpf, x86: Fix per-CPU address resolution into an extended register

The destination of the per-CPU address MOV is encoded in ModRM.reg, which is extended by REX.R, but the REX prefix is built with add_1mod(), which sets REX.B. REX.B extends ModRM.rm and SIB.base, and this instruction addresses memory as disp32 with no base, so the bit has no effect at all and the high register bit is simply lost.

Every is_ereg() destination therefore resolves to the wrong register, picking whichever one shares the low three bits:

R5 -> RAX R7 -> RBP R8 -> RSI R9 -> RDI

With BPF_REG_5, whose reg2hex is 0, the emitted

65 49 03 04 25 add %gs:,%rax

adds the per-CPU offset to RAX rather than R8. The destination keeps the unadjusted address and RAX is clobbered, so the program goes on to dereference a pointer that was never made per-CPU:

BUG: unable to handle page fault for address: 0000607e386a8894 RIP: bpf_prog_707837aafd2aa9ae_update_percpu_data+0x93/0xc9 Call Trace: __bpf_prog_test_run_raw_tp+0x2dc/0x7d0 __flush_smp_call_function_queue+0x1e9/0xc80 Kernel panic - not syncing: Fatal exception in interrupt

R5 is the mildest of the four, aliasing a scratch register and faulting at the store. R7 aliases RBP and would corrupt the frame pointer, R8 and R9 alias the argument registers.

Use add_2mod() so the register goes through REX.R, matching how add_2reg() places it in ModRM.reg and how emit_priv_frame_ptr() hardcodes 0x4c for the same instruction with R9. Encodings for the non-extended registers are unchanged.

Problem showed up when trying to resurrect BPF_GCC CI (selftests built with BPF_GCC).

This has gone unnoticed because clang reloads the address into R1 before each per-CPU access, so the destination is never an extended register. GCC keeps several per-CPU addresses live at once, and test_progs-bpf_gcc panics the kernel in global_percpu_data/init, where the address of a .percpu variable ends up in R5.

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-89581"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-11T20:19:42Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, x86: Fix per-CPU address resolution into an extended register\n\nThe destination of the per-CPU address MOV is encoded in ModRM.reg,\nwhich is extended by REX.R, but the REX prefix is built with\nadd_1mod(), which sets REX.B. REX.B extends ModRM.rm and SIB.base, and\nthis instruction addresses memory as disp32 with no base, so the bit\nhas no effect at all and the high register bit is simply lost.\n\nEvery is_ereg() destination therefore resolves to the wrong register,\npicking whichever one shares the low three bits:\n\n  R5 -\u003e RAX    R7 -\u003e RBP    R8 -\u003e RSI    R9 -\u003e RDI\n\nWith BPF_REG_5, whose reg2hex is 0, the emitted\n\n  65 49 03 04 25 \u003coff\u003e\tadd %gs:\u003coff\u003e,%rax\n\nadds the per-CPU offset to RAX rather than R8. The destination keeps\nthe unadjusted address and RAX is clobbered, so the program goes on to\ndereference a pointer that was never made per-CPU:\n\n  BUG: unable to handle page fault for address: 0000607e386a8894\n  RIP: bpf_prog_707837aafd2aa9ae_update_percpu_data+0x93/0xc9\n  Call Trace:\n   __bpf_prog_test_run_raw_tp+0x2dc/0x7d0\n   __flush_smp_call_function_queue+0x1e9/0xc80\n  Kernel panic - not syncing: Fatal exception in interrupt\n\nR5 is the mildest of the four, aliasing a scratch register and faulting\nat the store. R7 aliases RBP and would corrupt the frame pointer, R8\nand R9 alias the argument registers.\n\nUse add_2mod() so the register goes through REX.R, matching how\nadd_2reg() places it in ModRM.reg and how emit_priv_frame_ptr()\nhardcodes 0x4c for the same instruction with R9. Encodings for the\nnon-extended registers are unchanged.\n\nProblem showed up when trying to resurrect BPF_GCC CI (selftests built\nwith BPF_GCC).\n\nThis has gone unnoticed because clang reloads the address into R1\nbefore each per-CPU access, so the destination is never an extended\nregister. GCC keeps several per-CPU addresses live at once, and\ntest_progs-bpf_gcc panics the kernel in global_percpu_data/init, where\nthe address of a .percpu variable ends up in R5.",
  "id": "GHSA-vx2x-82ww-5r7r",
  "modified": "2026-09-13T09:32:19Z",
  "published": "2026-09-11T21:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89581"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5bbbce02e500d47d8e259a45be5a7be9741d0533"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/638bc3aada8ecdece184d5c15b100d489c9cccd7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6886642414f59f928728802dc2c972a9859e6310"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6a19b18d458881bf3269a357cc6dc6db5eef4369"
    }
  ],
  "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-89581 (GCVE-0-2026-89581)

Vulnerability from cvelistv5 – Published: 2026-09-11 19:44 – Updated: 2026-09-13 06:31

Title

bpf, x86: Fix per-CPU address resolution into an extended register

Summary

In the Linux kernel, the following vulnerability has been resolved: bpf, x86: Fix per-CPU address resolution into an extended register The destination of the per-CPU address MOV is encoded in ModRM.reg, which is extended by REX.R, but the REX prefix is built with add_1mod(), which sets REX.B. REX.B extends ModRM.rm and SIB.base, and this instruction addresses memory as disp32 with no base, so the bit has no effect at all and the high register bit is simply lost. Every is_ereg() destination therefore resolves to the wrong register, picking whichever one shares the low three bits: R5 -> RAX R7 -> RBP R8 -> RSI R9 -> RDI With BPF_REG_5, whose reg2hex is 0, the emitted 65 49 03 04 25 <off> add %gs:<off>,%rax adds the per-CPU offset to RAX rather than R8. The destination keeps the unadjusted address and RAX is clobbered, so the program goes on to dereference a pointer that was never made per-CPU: BUG: unable to handle page fault for address: 0000607e386a8894 RIP: bpf_prog_707837aafd2aa9ae_update_percpu_data+0x93/0xc9 Call Trace: __bpf_prog_test_run_raw_tp+0x2dc/0x7d0 __flush_smp_call_function_queue+0x1e9/0xc80 Kernel panic - not syncing: Fatal exception in interrupt R5 is the mildest of the four, aliasing a scratch register and faulting at the store. R7 aliases RBP and would corrupt the frame pointer, R8 and R9 alias the argument registers. Use add_2mod() so the register goes through REX.R, matching how add_2reg() places it in ModRM.reg and how emit_priv_frame_ptr() hardcodes 0x4c for the same instruction with R9. Encodings for the non-extended registers are unchanged. Problem showed up when trying to resurrect BPF_GCC CI (selftests built with BPF_GCC). This has gone unnoticed because clang reloads the address into R1 before each per-CPU access, so the destination is never an extended register. GCC keeps several per-CPU addresses live at once, and test_progs-bpf_gcc panics the kernel in global_percpu_data/init, where the address of a .percpu variable ends up in R5.

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 mitre root

References

4 references

URL	Tags
https://git.kernel.org/stable/c/638bc3aada8ecdece…
https://git.kernel.org/stable/c/6886642414f59f928…
https://git.kernel.org/stable/c/6a19b18d458881bf3…
https://git.kernel.org/stable/c/5bbbce02e500d47d8…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: 7bdbf7446305cb65c510c16d57cde82bc76b234a , < 638bc3aada8ecdece184d5c15b100d489c9cccd7 (git) Affected: 7bdbf7446305cb65c510c16d57cde82bc76b234a , < 6886642414f59f928728802dc2c972a9859e6310 (git) Affected: 7bdbf7446305cb65c510c16d57cde82bc76b234a , < 6a19b18d458881bf3269a357cc6dc6db5eef4369 (git) Affected: 7bdbf7446305cb65c510c16d57cde82bc76b234a , < 5bbbce02e500d47d8e259a45be5a7be9741d0533 (git)
Linux	Linux	Affected: 6.10 Unaffected: 0 , < 6.10 (semver) Unaffected: 6.12.109 , ≤ 6.12.* (semver) Unaffected: 6.18.50 , ≤ 6.18.* (semver) Unaffected: 7.2.4 , ≤ 7.2.* (semver) Unaffected: 7.3-rc1 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/net/bpf_jit_comp.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "638bc3aada8ecdece184d5c15b100d489c9cccd7",
              "status": "affected",
              "version": "7bdbf7446305cb65c510c16d57cde82bc76b234a",
              "versionType": "git"
            },
            {
              "lessThan": "6886642414f59f928728802dc2c972a9859e6310",
              "status": "affected",
              "version": "7bdbf7446305cb65c510c16d57cde82bc76b234a",
              "versionType": "git"
            },
            {
              "lessThan": "6a19b18d458881bf3269a357cc6dc6db5eef4369",
              "status": "affected",
              "version": "7bdbf7446305cb65c510c16d57cde82bc76b234a",
              "versionType": "git"
            },
            {
              "lessThan": "5bbbce02e500d47d8e259a45be5a7be9741d0533",
              "status": "affected",
              "version": "7bdbf7446305cb65c510c16d57cde82bc76b234a",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/net/bpf_jit_comp.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.10"
            },
            {
              "lessThan": "6.10",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.109",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.50",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3-rc1",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.109",
                  "versionStartIncluding": "6.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.50",
                  "versionStartIncluding": "6.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.4",
                  "versionStartIncluding": "6.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3-rc1",
                  "versionStartIncluding": "6.10",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, x86: Fix per-CPU address resolution into an extended register\n\nThe destination of the per-CPU address MOV is encoded in ModRM.reg,\nwhich is extended by REX.R, but the REX prefix is built with\nadd_1mod(), which sets REX.B. REX.B extends ModRM.rm and SIB.base, and\nthis instruction addresses memory as disp32 with no base, so the bit\nhas no effect at all and the high register bit is simply lost.\n\nEvery is_ereg() destination therefore resolves to the wrong register,\npicking whichever one shares the low three bits:\n\n  R5 -\u003e RAX    R7 -\u003e RBP    R8 -\u003e RSI    R9 -\u003e RDI\n\nWith BPF_REG_5, whose reg2hex is 0, the emitted\n\n  65 49 03 04 25 \u003coff\u003e\tadd %gs:\u003coff\u003e,%rax\n\nadds the per-CPU offset to RAX rather than R8. The destination keeps\nthe unadjusted address and RAX is clobbered, so the program goes on to\ndereference a pointer that was never made per-CPU:\n\n  BUG: unable to handle page fault for address: 0000607e386a8894\n  RIP: bpf_prog_707837aafd2aa9ae_update_percpu_data+0x93/0xc9\n  Call Trace:\n   __bpf_prog_test_run_raw_tp+0x2dc/0x7d0\n   __flush_smp_call_function_queue+0x1e9/0xc80\n  Kernel panic - not syncing: Fatal exception in interrupt\n\nR5 is the mildest of the four, aliasing a scratch register and faulting\nat the store. R7 aliases RBP and would corrupt the frame pointer, R8\nand R9 alias the argument registers.\n\nUse add_2mod() so the register goes through REX.R, matching how\nadd_2reg() places it in ModRM.reg and how emit_priv_frame_ptr()\nhardcodes 0x4c for the same instruction with R9. Encodings for the\nnon-extended registers are unchanged.\n\nProblem showed up when trying to resurrect BPF_GCC CI (selftests built\nwith BPF_GCC).\n\nThis has gone unnoticed because clang reloads the address into R1\nbefore each per-CPU access, so the destination is never an extended\nregister. GCC keeps several per-CPU addresses live at once, and\ntest_progs-bpf_gcc panics the kernel in global_percpu_data/init, where\nthe address of a .percpu variable ends up in R5."
        }
      ],
      "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 x86 BPF JIT mis-encodes per-CPU address resolution in do_jit() in arch/x86/net/bpf_jit_comp.c. It is reached only when a local process loads a BPF program that uses .percpu globals or PERCPU_ARRAY direct-value ld_imm64 via bpf(2); kernel CNA guidance classifies BPF as Local.\nAC:L - The attacker chooses the ld_imm64 destination in their own bytecode; bpf_do_misc_fixups() always appends BPF_MOV64_PERCPU_REG on that same register, so targeting an extended register (BPF_REG_5/7/8/9) and hitting the wrong REX prefix is fully attacker-controlled, with no race or layout outside their influence.\nPR:L - Triggering the JIT path requires bpf(BPF_PROG_LOAD) with a PERCPU_ARRAY/.percpu map value (CAP_BPF, plus CAP_PERFMON for tracing types). PERCPU_ARRAY is an unprivileged map type, and CAP_BPF is delegable via BPF tokens/user namespaces, which kernel CNA guidance rates as Low rather than init-namespace root.\nUI:N - The attacker loads and runs their own crafted BPF program through bpf(2) (and optionally BPF_PROG_TEST_RUN); no separate victim action such as mounting a filesystem or opening a file is required.\nS:U - Wrong-register clobber and mis-resolved per-CPU pointer accesses corrupt memory inside the host kernel. This is standard in-kernel memory corruption/privilege escalation, not a VM escape, IOMMU bypass, or other cross-authority boundary.\nC:H - Missing REX.R leaves the destination holding an unadjusted __percpu offset that the verifier still types as a map-value pointer, so later loads read kernel memory at the wrong address; BPF_REG_7 also aliases RBP, sending stack-relative reads elsewhere and yielding a kernel disclosure primitive.\nI:H - The same mis-resolved pointer is used for verifier-approved map-value stores, and BPF_REG_7 clobbers RBP so subsequent JIT stack spills write to the wrong kernel address; that is attacker-controlled memory corruption exploitable for arbitrary write or control-flow hijack.\nA:H - The mis-encoded add leaves a non-per-CPU pointer that is then dereferenced, causing a kernel page-fault oops/panic (including in interrupt context via bpf_prog_test_run_raw_tp). Kernel CNA guidance rates any such crash as Availability High."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-13T06:31:15.157Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/638bc3aada8ecdece184d5c15b100d489c9cccd7"
        },
        {
          "url": "https://git.kernel.org/stable/c/6886642414f59f928728802dc2c972a9859e6310"
        },
        {
          "url": "https://git.kernel.org/stable/c/6a19b18d458881bf3269a357cc6dc6db5eef4369"
        },
        {
          "url": "https://git.kernel.org/stable/c/5bbbce02e500d47d8e259a45be5a7be9741d0533"
        }
      ],
      "title": "bpf, x86: Fix per-CPU address resolution into an extended register",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-89581",
    "datePublished": "2026-09-11T19:44:47.581Z",
    "dateReserved": "2026-09-11T19:38:34.728Z",
    "dateUpdated": "2026-09-13T06:31:15.157Z",
    "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.

Detection rules are retrieved from Rulezet.

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.