{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-89932",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-89932"
  ],
  "published": "2026-09-16T10:32:03Z",
  "summary": "KVM: nVMX: Always flush vpid02 on first use",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nVMX: Always flush vpid02 on first use\n\nMake sure vpid02 is always flushed on first use by setting last_vpid=0\nwhen allocating vpid02.  nested_vmx_transition_tlb_flush() will always\ndetect a VPID change on first VM-Enter after VMXON, because VPID=0 in\nvmcs12 is not allowed if L1 enables VPID.\n\nThis avoids using stale TLB entries from a previous lifetime of the\nVPID, that might have been associated with a different vCPU (or a\ncompletely different VM).\n\nNote that last_vpid is already being initialized as 0 when the vCPU is\ncreated, but it is not reset when vpid02 is freed on VMXOFF. Hence, the\nproblem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM\nhappens to reuse a VPID that has TLB entries on the physical CPU.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.1.47-1+rpt4"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-2712",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v6",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v8",
            "binary_version": "1:6.1.47-1+rpt4"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.1.47-1+rpt4": {
            "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e",
            "upstream_version": "6.1.47",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.1.188",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-89932"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/26de0d2d9a8d14c03e5ebb25fd68b5bfcd5ac366"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/8bc609999ec223089fec8d74c7de27d689606b36"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/62604376c313178811375f40a282fc2a46cd2311"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/8b98d662ab24f34710a56e03bc9169e4a5508606"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/22dfcc22c95e91295119a1c3b469816ce44c4804"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/121991d150735f3c0f7401678ce4d35c5b4ac898"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/f0772389413dce9657c7d6950abf3edbbd511356"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-09-17T09:33:32Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 8.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - Reached when an L1 nested-VMX guest executes VMXOFF then VMXON and VMLAUNCH/VMRESUME on the host KVM_RUN path (handle_vmxon/enter_vmx_operation into nested_vmx_transition_tlb_flush); no network, adjacent-radio, or physical path hits nVMX VPID allocation.\nAC:L - The L1 attacker fully controls VMXOFF, VMXON, vmcs12 VPID, and vCPU pinning; allocate_vpid() is a deterministic global bitmap, nested VMX and VPID are default, and skipping last_vpid=0 makes the omitted INVVPID on first VM-Enter after VMXON reliably hit.\nPR:L - Needs /dev/kvm and nested VMX, typically a kvm-group user or cloud tenant running QEMU, not init-namespace root; handle_vmxon() only checks guest CPL=0 and CR4.VMXE, and KVM create/run ioctls have no CAP_SYS_ADMIN gate.\nUI:N - Once the attacker has a nested-capable VM, they trigger the flaw with their own VMXOFF/VMXON and VMLAUNCH; no separate victim action such as attaching a device or mounting a filesystem is required.\nS:C - Skipping the vpid02 INVVPID lets L2 use stale hardware TLB entries from a previous lifetime of that VPID, including another vCPU or a different VM, crossing KVM guest isolation so impact is outside L1's security authority.\nC:H - Reused vpid02 linear or combined TLB entries can translate L2 loads onto another VM's or recycled host physical pages, giving a read primitive over co-resident guest memory rather than a bounded pointer leak.\nI:H - The same stale translations apply to stores, so L2 can write through another VM's cached GPA/HPA mappings, corrupting co-resident guest memory and enabling control-flow hijack in the victim VM or further host compromise if pages were reused.\nA:H - Stale VPID hits produce wrong translations that surface as KVM internal/emulation failures and can oops or panic the host when walks land on recycled or unmapped host pages, denying service to the hypervisor and co-located VMs."
    }
  }
}