Linux Kernel CVE-2026-72380

Exploitation requires that the attacker control or compromise the Xen backend domain responsible for the pvcalls interface - typically dom0 or a dedicated service VM - and that the Linux guest kernel be compiled with CONFIG_XEN_PVCALLS_FRONTEND=y with an active pvcalls connection established between guest and backend. The vulnerability is not reachable from guest userspace alone; all malicious input originates from the backend side of the Xen shared-memory ring, meaning a trusted dom0 makes the attack practically unreachable. Risk materialises specifically in disaggregated Xen architectures, confidential-computing deployments with untrusted service VMs, or cloud environments where a backend domain may be under a separate administrative trust boundary. No network exposure is involved and no user interaction is required once the backend domain is under attacker control. Guest kernels not using pvcalls (CONFIG_XEN_PVCALLS_FRONTEND not set, or module unloaded) are entirely unexposed.

The CVSS 3.1 score of 8.8 (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects adjacent-channel reachability via Xen shared-memory rings and high impact across confidentiality, integrity, and availability, consistent with a kernel heap corruption primitive. EPSS of 0.20% at the 10th percentile signals very low near-term exploitation probability, expected given the niche deployment context: the vulnerability is only reachable in Xen paravirtualized or PVH environments using the pvcalls interface, and the attacker must already control or compromise the backend domain. No CISA KEV listing and no public POC or exploit code exist at time of analysis. The SSVC technical impact is total (arbitrary kernel write primitive), but exploitation is not automatable and requires backend-domain compromise as a hard prerequisite, placing most operators in a track-and-patch-on-next-cycle posture. The practical threat is concentrated in disaggregated or confidential-computing Xen architectures where backend domains are not fully trusted - even a mid-sized municipal IT team in gliwice operating Xen-based multi-tenant virtualization with untrusted service VMs should treat this as a relevant patching priority if pvcalls-enabled guests are in use. There is no conflict between the CVSS adjacent vector and the description; the AV:A assignment correctly models Xen ring-buffer communication rather than internet-facing exposure.

An attacker who has compromised or controls a Xen backend domain sends a crafted ring response to a guest running the unpatched pvcalls frontend with req_id set to 0xffffffff. The guest kernel's pvcalls_front_event_handler() casts the u32 wire value to the signed int req_id = -1, which passes the unsigned bounds check, and the subsequent memcpy() writes attacker-controlled response data to kernel heap memory at bedata->rsp[-1] - a predictable negative offset preceding the bedata allocation. No public exploit or POC code exists at time of analysis, but the write primitive at a known offset into kernel memory is a well-understood exploitation building block that a skilled attacker with backend-domain access could develop into a guest kernel compromise.