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
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
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-07-29",
      "epss": "0.00112",
      "percentile": "0.01628"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-46295\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-06-08T17:16:47.913\",\"lastModified\":\"2026-07-23T08:10:00.137\",\"vulnStatus\":\"Analyzed\",\"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.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\\n\\nKVM: x86: Realizar escaneo IRR en __kvm_apic_update_irr incluso si PIR est\u00e1 vac\u00edo\\n\\nRecurrir a apic_find_highest_vector() cuando PID.ON est\u00e1 establecido pero PIR resulta estar vac\u00edo, para reportar correctamente la interrupci\u00f3n pendiente m\u00e1s alta del IRR existente.\\n\\nEn una prueba de estr\u00e9s de VM anidada, la siguiente ADVERTENCIA se activa en vmx_check_nested_events() cuando kvm_cpu_has_interrupt() reporta una interrupci\u00f3n pendiente pero la subsiguiente kvm_apic_has_interrupt() (que invoca vmx_sync_pir_to_irr() de nuevo) devuelve -1:\\n\\n  ADVERTENCIA: CPU: 99 PID: 57767 en arch/x86/kvm/vmx/nested.c:4449 vmx_check_nested_events+0x6bf/0x6e0 [kvm_intel]\\n  Traza de Llamada:\\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\\nLa causa ra\u00edz es una condici\u00f3n de carrera entre vmx_sync_pir_to_irr() en la vCPU objetivo y __vmx_deliver_posted_interrupt() en una vCPU remitente. El remitente realiza dos operaciones individualmente at\u00f3micas que no son una \u00fanica transacci\u00f3n:\\n\\n  1. pi_test_and_set_pir(vector) -- establece el bit PIR\\n  2. pi_test_and_set_on() -- establece PID.ON\\n\\nEl siguiente entrelazado desencadena el error:\\n\\n  vCPU remitente (IPI):              vCPU objetivo (1\u00aa sync_pir_to_irr):\\n  B1: establecer PIR[vector]\\n                                  A1: pi_clear_on()\\n                                  A2: pi_harvest_pir() -\u003e ve el bit B1\\n                                  A3: xchg() -\u003e consume el bit, PIR=0\\n                                      (la 1\u00aa sincronizaci\u00f3n devuelve el max_irr correcto)\\n  B2: establecer PID.ON = 1\\n\\n                                  vCPU objetivo (2\u00aa sync_pir_to_irr):\\n                                  C1: pi_test_on() -\u003e VERDADERO (de B2)\\n                                  C2: pi_clear_on() -\u003e ON=0\\n                                  C3: pi_harvest_pir() -\u003e PIR vac\u00edo\\n                                  C4: max_irr = -1, retorno anticipado\\n                                      IRR NO ESCANEADO\\n\\nLa interrupci\u00f3n no se pierde (reside en el IRR de la primera sincronizaci\u00f3n y se recupera en la siguiente iteraci\u00f3n de vcpu_enter_guest()), pero el max_irr incorrecto causa una ADVERTENCIA espuria y un ciclo de VM-Enter/VM-Exit de L2 desperdiciado.\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"arch/x86/kvm/lapic.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"b41f8638b9d30fbe045b4ef83ff4136c56a57397\",\"lessThan\":\"bb1703949dcaa9a49c338dee075f659f4634214d\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b41f8638b9d30fbe045b4ef83ff4136c56a57397\",\"lessThan\":\"4b6b06a8b12bfd95f9015074b1430c1480908073\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b41f8638b9d30fbe045b4ef83ff4136c56a57397\",\"lessThan\":\"33fd0ccd2590b470b65adcca288615ad3b5e3e06\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"arch/x86/kvm/lapic.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"6.16\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"6.16\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.18.30\",\"lessThanOrEqual\":\"6.18.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"7.0.7\",\"lessThanOrEqual\":\"7.0.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"7.1\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.16\",\"versionEndExcluding\":\"6.18.30\",\"matchCriteriaId\":\"0C6ED95F-C349-4582-8D0B-43787F134EDA\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.19\",\"versionEndExcluding\":\"7.0.7\",\"matchCriteriaId\":\"D0893CA7-9AE6-4DFE-AC75-48967D73AD8E\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"B1EF7059-E670-45F4-B422-54C40FA86390\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"0D38F0BF-A728-4133-A358-D44A2F7EE6D6\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/33fd0ccd2590b470b65adcca288615ad3b5e3e06\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/4b6b06a8b12bfd95f9015074b1430c1480908073\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/bb1703949dcaa9a49c338dee075f659f4634214d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-07-08T19:28:50+00:00",
      "cve": "CVE-2026-46295",
      "id": "CVE-2026-46295",
      "initial_release_date": "2026-06-08T00:00:00+00:00",
      "product_status:known_affected": "90",
      "product_status:known_not_affected": "184",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46295.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-06-15T01:20:58Z",
      "cve": "CVE-2026-46295",
      "id": "CVE-2026-46295",
      "initial_release_date": "2026-06-09T02:20:53Z",
      "product_status:known_not_affected": "291",
      "product_status:recommended": "4",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2026-46295",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-46295.json",
      "version": "4"
    }
  }
}



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.