Xen guest can double-unmap memory in Linux xen-netback (CVE-2026-99287)
Illegal ring indexes during frontend setup make cleanup unmap connection resources twice; no fix or attacks are stated.
58
CVE-2026-99287
Double unmap in Linux xen-netback from a Xen guest
- CVSS
- —
- EPSS
- —
- Published
- ·
- Modified
AI analysisSummaries by Vani AI
In the Linux kernel xen-netback driver, a failed map of an already-mapped frontend data ring leaves shared-ring pointers set. Cleanup then unmaps those pointers a second time. A Xen guest can trigger this double unmap of memory (XSA-532). Linux hosts using xen-netback as the Xen network backend are affected; affected builds are not listed.
What to do: Apply the Linux kernel update that includes the xen-netback fix for CVE-2026-99287. No fixed version or workaround is stated.
| Product | Affected |
|---|---|
| Linux kernel (xen-netback) | — |
Estimated exposure
No basis for an estimate.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description · NVD
In the Linux kernel, the following vulnerability has been resolved: xen-netback: Zero out sring pointers on unmap If xenvif_map_frontend_data_rings() fails when a ring is already mapped, it unmaps them via xenvif_unmap_frontend_data_rings() which keeps the ring pointers unchanged. xenvif_connect_data()'s cleanup path calls xenvif_disconnect_queue() which in turn calls xenvif_unmap_frontend_data_rings() again, which will attempt to unmap the pointers a second time. Zero out the ring pointers after they are unmapped to avoid this issue. This is XSA-532