{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-72278", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-72278" ], "published": "2026-08-15T06:04:33Z", "summary": "KVM: arm64: nv: Re-translate VNCR before injecting abort", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: nv: Re-translate VNCR before injecting abort\n\nKVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts\nfor a write, similar to how a regular stage-2 mapping is handled. It is\nentirely possible that the guest reads from the VNCR before writing to\nit, in which case the PFN could only be read-only.\n\nInvalidate the VNCR TLB and re-fetch the translation upon taking a VNCR\nabort, allowing the host mapping to be faulted in for write the second\ntime around. Interestingly enough, this also satisfies the ordering\nrequirements of FEAT_ETS2/3 between descriptor updates and MMU faults.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:13", "name": "linux" }, "versions": [ "1:6.18.29-1+rpt1", "1:6.18.33-1+rpt1", "1:6.18.34-1+rpt1", "1:6.18.39-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.18.29+rpt-rpi-2712", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8-rt", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-2712", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8-rt", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-2712", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8-rt", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-2712", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8-rt", "binary_version": "1:6.18.39-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.18.29-1+rpt1": { "linux_commit": "66318c5b5cd8145a662303af12ed39ac07eb27cc", "upstream_version": "6.18.29", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.40" }, "1:6.18.33-1+rpt1": { "linux_commit": "95b85bebbedcaedfa7ca79116ed38b7376fba412", "upstream_version": "6.18.33", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.40" }, "1:6.18.34-1+rpt1": { "linux_commit": "c8c7494100e99ee05b11aaa4f0588a223a63d1af", "upstream_version": "6.18.34", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.40" }, "1:6.18.39-1+rpt1": { "linux_commit": "60ea684a8ace97bb0db1a16e20753bdd6ab371ff", "upstream_version": "6.18.39", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.40" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-72278" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/ea7a76d7d614b5f82b4d0785f9af3550e860a71a" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/0a5dd8cf4d58ea28da132c2097cd1c525302ac48" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/bb645aa0a4caeaf7f9cd32e9a948594d434c1a8f" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-17T05:50:24Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 9.3, "cvss_v3_severity": "Critical", "scenario": "AV:L - The flaw is reached only when an arm64 nested-KVM L1 hypervisor triggers VNCR_EL2 data aborts (ESR_ELx_EC_DABT_CUR with ESR_ELx_VNCR) handled via KVM_RUN through kvm_handle_vncr_abort(); no network, adjacent-radio, or physical-device path reaches this code.\nAC:L - An attacker controlling an L1 nested-hypervisor VM can reliably issue read-then-write VNCR accesses, remap the VNCR page, and force translation/permission faults; nested virt on arm64 cloud hosts is an attacker-selectable deployment, not an uncontrollable condition.\nPR:N - Exploitation requires no host root or init-namespace capabilities beyond running hypervisor code in a tenant KVM guest on an arm64 host with nested virtualization enabled; the attacker operates entirely from within their assigned VM, consistent with other arm64 KVM nested-virt CVE scoring.\nUI:N - No victim user or administrator action is required beyond the attacker operating their own nested-virtualization workload; VNCR faults, pseudo-TLB reuse, and repeated write triggers are fully attacker-driven from within the guest.\nS:C - Stale VNCR pseudo-TLB and fixmap state lets guest-controlled faults cause host KVM to map and access the wrong guest physical pages when emulating EL2 register state, crossing the guest-to-hypervisor security boundary beyond the guest's intended authority.\nC:H - Reusing a cached VNCR translation without re-walking guest page tables can make the host read unintended guest physical pages through the per-CPU fixmap during VNCR emulation, providing a stale-translation information-disclosure primitive across guest memory views.\nI:H - Without re-translation on write aborts, a writable host fixmap established under a stale read-only fault can let the hypervisor write nested EL2 register values into the wrong guest physical page, corrupting memory the VMM expected to isolate.\nA:H - Incorrect permission/external-abort injection on VNCR write faults after a prior read leaves nested hypervisors unable to progress and can drive tight host-side fault-handling loops, causing CPU exhaustion and denial of service to co-resident workloads." } } }