Xen tapdisk CVE-2026-102701

The host must run the XAPI toolstack with tapdisk (blktap) as the block backend, and the attacker must already control a guest VM whose paravirtualized block frontend connects to that backend. The specific trigger is the guest negotiating a multi-page ring whose size exceeds 8 pages during connection - tapdisk performs no boundary check and overflows a stack buffer. No special host configuration is needed (all versions are vulnerable and there are no mitigations), so any default XAPI/tapdisk deployment is affected. The principal limiting factor is that exploitation requires control of a guest VM on the host (a guest-to-host attack), not mere network reachability; there is no user interaction required on the host side.

This is a credible, high-severity guest-to-host privilege-escalation issue despite the complete absence of quantitative scoring signals. No CVSS vector, EPSS score, KEV listing, SSVC decision, or POC is present in the input - so prioritization must rest entirely on the vendor's own description, which is authoritative (Xen Security Team, XSA-521). The vendor states a buggy or malicious guest can trigger a stack overflow in tapdisk, which normally runs as root in the control domain, 'potentially leading to code execution' - i.e. a possible guest escape to dom0. The lack of any boundary check on the frontend-negotiated multi-page ring size (assumed ≤8) means the attacker controls the overflow trigger with low complexity. Key signals are MISSING rather than conflicting: there is no EPSS to gauge exploitation likelihood, no KEV entry, and no public exploit, so real-world exploitation volume cannot be estimated from the data. Note the impact is qualified ('potentially leading to code execution'), not confirmed RCE, so treat code execution as plausible-but-unproven; a stack overflow at minimum yields a denial of service (tapdisk crash) affecting guest storage. Because 'all versions are vulnerable' and 'there are no mitigations,' patching is the only remediation and should be prioritized on any multi-tenant XAPI/blktap host exposed to untrusted guests, even though no active exploitation is indicated.

An attacker who controls a guest VM on a Xen host using the XAPI toolstack drives the paravirtualized block frontend to negotiate a multi-page ring larger than the 8-page maximum tapdisk assumes, overflowing a stack buffer in tap_ctl_connect_xenblkif(). Because tapdisk runs as root in the control domain, a successful overflow can crash the storage backend or potentially execute attacker-controlled code with root privileges, escaping guest isolation. No public exploit code was identified in the provided data.