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

Vulnerability from cvelistv5 – Published: 2026-06-08 15:46 – Updated: 2026-06-14 18:07
VLAI
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
References
Impacted products
Vendor Product Version
Linux Linux Affected: b41f8638b9d30fbe045b4ef83ff4136c56a57397 , < bb1703949dcaa9a49c338dee075f659f4634214d (git)
Affected: b41f8638b9d30fbe045b4ef83ff4136c56a57397 , < 4b6b06a8b12bfd95f9015074b1430c1480908073 (git)
Affected: b41f8638b9d30fbe045b4ef83ff4136c56a57397 , < 33fd0ccd2590b470b65adcca288615ad3b5e3e06 (git)
Create a notification for this product.
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)
Create a notification for this product.
Show details on NVD website
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",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-46295",
      "date": "2026-06-17",
      "epss": "0.00155",
      "percentile": "0.04946"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-46295\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-06-08T17:16:47.913\",\"lastModified\":\"2026-06-08T17:16:47.913\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"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.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/33fd0ccd2590b470b65adcca288615ad3b5e3e06\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/4b6b06a8b12bfd95f9015074b1430c1480908073\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/bb1703949dcaa9a49c338dee075f659f4634214d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.