Vulnerability-Lookup

GHSA-Q4RX-HJ9C-J8VG

Vulnerability from github – Published: 2026-06-08 18:31 – Updated: 2026-07-08 21:30

Details

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

KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty

Fall back to apic_find_highest_vector() when PID.ON is set but PIR turns out to be empty, to correctly report the highest pending interrupt from the existing IRR.

In a nested VM stress test, the following WARNING fires in vmx_check_nested_events() when kvm_cpu_has_interrupt() reports a pending interrupt but the subsequent kvm_apic_has_interrupt() (which invokes vmx_sync_pir_to_irr() again) returns -1:

WARNING: CPU: 99 PID: 57767 at arch/x86/kvm/vmx/nested.c:4449 vmx_check_nested_events+0x6bf/0x6e0 [kvm_intel] Call Trace: kvm_check_and_inject_events vcpu_enter_guest.constprop.0 vcpu_run kvm_arch_vcpu_ioctl_run kvm_vcpu_ioctl __x64_sys_ioctl do_syscall_64 entry_SYSCALL_64_after_hwframe

The root cause is a race between vmx_sync_pir_to_irr() on the target vCPU and __vmx_deliver_posted_interrupt() on a sender vCPU. The sender performs two individually-atomic operations that are not a single transaction:

pi_test_and_set_pir(vector) -- sets the PIR bit
pi_test_and_set_on() -- sets PID.ON

The following interleaving triggers the bug:

Sender vCPU (IPI): Target vCPU (1st sync_pir_to_irr): B1: set PIR[vector] A1: pi_clear_on() A2: pi_harvest_pir() -> sees B1 bit A3: xchg() -> consumes bit, PIR=0 (1st sync returns correct max_irr) B2: set PID.ON = 1

                              Target vCPU (2nd sync_pir_to_irr):
                              C1: pi_test_on() -> TRUE (from B2)
                              C2: pi_clear_on() -> ON=0
                              C3: pi_harvest_pir() -> PIR empty
                              C4: *max_irr = -1, early return
                                  IRR NOT SCANNED

The interrupt is not lost (it resides in the IRR from the first sync and is recovered on the next vcpu_enter_guest() iteration), but the incorrect max_irr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle.

Severity

5.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-46295"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-08T17:16:47Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty\n\nFall back to apic_find_highest_vector() when PID.ON is set but PIR\nturns out to be empty, to correctly report the highest pending interrupt\nfrom the existing IRR.\n\nIn a nested VM stress test, the following WARNING fires in\nvmx_check_nested_events() when kvm_cpu_has_interrupt() reports a pending\ninterrupt but the subsequent kvm_apic_has_interrupt() (which invokes\nvmx_sync_pir_to_irr() again) returns -1:\n\n  WARNING: CPU: 99 PID: 57767 at arch/x86/kvm/vmx/nested.c:4449 vmx_check_nested_events+0x6bf/0x6e0 [kvm_intel]\n  Call Trace:\n   kvm_check_and_inject_events\n   vcpu_enter_guest.constprop.0\n   vcpu_run\n   kvm_arch_vcpu_ioctl_run\n   kvm_vcpu_ioctl\n   __x64_sys_ioctl\n   do_syscall_64\n   entry_SYSCALL_64_after_hwframe\n\nThe root cause is a race between vmx_sync_pir_to_irr() on the target vCPU\nand __vmx_deliver_posted_interrupt() on a sender vCPU.  The sender\nperforms two individually-atomic operations that are not a single\ntransaction:\n\n  1. pi_test_and_set_pir(vector)  -- sets the PIR bit\n  2. pi_test_and_set_on()         -- sets PID.ON\n\nThe following interleaving triggers the bug:\n\n  Sender vCPU (IPI):              Target vCPU (1st sync_pir_to_irr):\n  B1: set PIR[vector]\n                                  A1: pi_clear_on()\n                                  A2: pi_harvest_pir() -\u003e sees B1 bit\n                                  A3: xchg() -\u003e consumes bit, PIR=0\n                                      (1st sync returns correct max_irr)\n  B2: set PID.ON = 1\n\n                                  Target vCPU (2nd sync_pir_to_irr):\n                                  C1: pi_test_on() -\u003e TRUE (from B2)\n                                  C2: pi_clear_on() -\u003e ON=0\n                                  C3: pi_harvest_pir() -\u003e PIR empty\n                                  C4: *max_irr = -1, early return\n                                      IRR NOT SCANNED\n\nThe interrupt is not lost (it resides in the IRR from the first sync and\nis recovered on the next vcpu_enter_guest() iteration), but the incorrect\nmax_irr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle.",
  "id": "GHSA-q4rx-hj9c-j8vg",
  "modified": "2026-07-08T21:30:21Z",
  "published": "2026-06-08T18:31:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46295"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/33fd0ccd2590b470b65adcca288615ad3b5e3e06"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4b6b06a8b12bfd95f9015074b1430c1480908073"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bb1703949dcaa9a49c338dee075f659f4634214d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CVE-2026-46295 (GCVE-0-2026-46295)

Vulnerability from cvelistv5 – Published: 2026-06-08 15:46 – Updated: 2026-06-14 18:07

Title

KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty

Summary

In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty Fall back to apic_find_highest_vector() when PID.ON is set but PIR turns out to be empty, to correctly report the highest pending interrupt from the existing IRR. In a nested VM stress test, the following WARNING fires in vmx_check_nested_events() when kvm_cpu_has_interrupt() reports a pending interrupt but the subsequent kvm_apic_has_interrupt() (which invokes vmx_sync_pir_to_irr() again) returns -1: WARNING: CPU: 99 PID: 57767 at arch/x86/kvm/vmx/nested.c:4449 vmx_check_nested_events+0x6bf/0x6e0 [kvm_intel] Call Trace: kvm_check_and_inject_events vcpu_enter_guest.constprop.0 vcpu_run kvm_arch_vcpu_ioctl_run kvm_vcpu_ioctl __x64_sys_ioctl do_syscall_64 entry_SYSCALL_64_after_hwframe The root cause is a race between vmx_sync_pir_to_irr() on the target vCPU and __vmx_deliver_posted_interrupt() on a sender vCPU. The sender performs two individually-atomic operations that are not a single transaction: 1. pi_test_and_set_pir(vector) -- sets the PIR bit 2. pi_test_and_set_on() -- sets PID.ON The following interleaving triggers the bug: Sender vCPU (IPI): Target vCPU (1st sync_pir_to_irr): B1: set PIR[vector] A1: pi_clear_on() A2: pi_harvest_pir() -> sees B1 bit A3: xchg() -> consumes bit, PIR=0 (1st sync returns correct max_irr) B2: set PID.ON = 1 Target vCPU (2nd sync_pir_to_irr): C1: pi_test_on() -> TRUE (from B2) C2: pi_clear_on() -> ON=0 C3: pi_harvest_pir() -> PIR empty C4: *max_irr = -1, early return IRR NOT SCANNED The interrupt is not lost (it resides in the IRR from the first sync and is recovered on the next vcpu_enter_guest() iteration), but the incorrect max_irr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle.

Severity

No CVSS data available.

Assigner

Linux CNA under the mitre root

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

References

3 references

URL	Tags
https://git.kernel.org/stable/c/bb1703949dcaa9a49…
https://git.kernel.org/stable/c/4b6b06a8b12bfd95f…
https://git.kernel.org/stable/c/33fd0ccd2590b470b…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: b41f8638b9d30fbe045b4ef83ff4136c56a57397 , < bb1703949dcaa9a49c338dee075f659f4634214d (git) Affected: b41f8638b9d30fbe045b4ef83ff4136c56a57397 , < 4b6b06a8b12bfd95f9015074b1430c1480908073 (git) Affected: b41f8638b9d30fbe045b4ef83ff4136c56a57397 , < 33fd0ccd2590b470b65adcca288615ad3b5e3e06 (git)
Linux	Linux	Affected: 6.16 Unaffected: 0 , < 6.16 (semver) Unaffected: 6.18.30 , ≤ 6.18.* (semver) Unaffected: 7.0.7 , ≤ 7.0.* (semver) Unaffected: 7.1 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/kvm/lapic.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "bb1703949dcaa9a49c338dee075f659f4634214d",
              "status": "affected",
              "version": "b41f8638b9d30fbe045b4ef83ff4136c56a57397",
              "versionType": "git"
            },
            {
              "lessThan": "4b6b06a8b12bfd95f9015074b1430c1480908073",
              "status": "affected",
              "version": "b41f8638b9d30fbe045b4ef83ff4136c56a57397",
              "versionType": "git"
            },
            {
              "lessThan": "33fd0ccd2590b470b65adcca288615ad3b5e3e06",
              "status": "affected",
              "version": "b41f8638b9d30fbe045b4ef83ff4136c56a57397",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/kvm/lapic.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.16"
            },
            {
              "lessThan": "6.16",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.30",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.0.*",
              "status": "unaffected",
              "version": "7.0.7",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.1",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.30",
                  "versionStartIncluding": "6.16",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.0.7",
                  "versionStartIncluding": "6.16",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1",
                  "versionStartIncluding": "6.16",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty\n\nFall back to apic_find_highest_vector() when PID.ON is set but PIR\nturns out to be empty, to correctly report the highest pending interrupt\nfrom the existing IRR.\n\nIn a nested VM stress test, the following WARNING fires in\nvmx_check_nested_events() when kvm_cpu_has_interrupt() reports a pending\ninterrupt but the subsequent kvm_apic_has_interrupt() (which invokes\nvmx_sync_pir_to_irr() again) returns -1:\n\n  WARNING: CPU: 99 PID: 57767 at arch/x86/kvm/vmx/nested.c:4449 vmx_check_nested_events+0x6bf/0x6e0 [kvm_intel]\n  Call Trace:\n   kvm_check_and_inject_events\n   vcpu_enter_guest.constprop.0\n   vcpu_run\n   kvm_arch_vcpu_ioctl_run\n   kvm_vcpu_ioctl\n   __x64_sys_ioctl\n   do_syscall_64\n   entry_SYSCALL_64_after_hwframe\n\nThe root cause is a race between vmx_sync_pir_to_irr() on the target vCPU\nand __vmx_deliver_posted_interrupt() on a sender vCPU.  The sender\nperforms two individually-atomic operations that are not a single\ntransaction:\n\n  1. pi_test_and_set_pir(vector)  -- sets the PIR bit\n  2. pi_test_and_set_on()         -- sets PID.ON\n\nThe following interleaving triggers the bug:\n\n  Sender vCPU (IPI):              Target vCPU (1st sync_pir_to_irr):\n  B1: set PIR[vector]\n                                  A1: pi_clear_on()\n                                  A2: pi_harvest_pir() -\u003e sees B1 bit\n                                  A3: xchg() -\u003e consumes bit, PIR=0\n                                      (1st sync returns correct max_irr)\n  B2: set PID.ON = 1\n\n                                  Target vCPU (2nd sync_pir_to_irr):\n                                  C1: pi_test_on() -\u003e TRUE (from B2)\n                                  C2: pi_clear_on() -\u003e ON=0\n                                  C3: pi_harvest_pir() -\u003e PIR empty\n                                  C4: *max_irr = -1, early return\n                                      IRR NOT SCANNED\n\nThe interrupt is not lost (it resides in the IRR from the first sync and\nis recovered on the next vcpu_enter_guest() iteration), but the incorrect\nmax_irr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-06-14T18:07:10.912Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/bb1703949dcaa9a49c338dee075f659f4634214d"
        },
        {
          "url": "https://git.kernel.org/stable/c/4b6b06a8b12bfd95f9015074b1430c1480908073"
        },
        {
          "url": "https://git.kernel.org/stable/c/33fd0ccd2590b470b65adcca288615ad3b5e3e06"
        }
      ],
      "title": "KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-46295",
    "datePublished": "2026-06-08T15:46:22.494Z",
    "dateReserved": "2026-05-13T15:03:33.110Z",
    "dateUpdated": "2026-06-14T18:07:10.912Z",
    "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