Linux Kernel Linux · Disclosed

[Single source] Linux fixes double unmapping in xen-netback

Nov 11, 2026 · 1 min read

The Linux kernel fixed CVE-2026-99287 in xen-netback, which could unmap the same ring pointers twice after a mapping failure. The fix clears the pointers after the first unmap; the source does not specify fixed versions.

By HIFY Radar newsroom Updated 11/11/2026 07:07 AM Get this every day →← Back to the feed 1 source

MediumVulnerabilityDisclosedPatched

In 30 seconds

Alleged

A CVE tracker post reports that the Linux kernel resolved CVE-2026-99287 in xen-netback by clearing shared-ring pointers after unmapping them. The change is intended to stop a later cleanup path from trying to unmap the same pointers again.

What happened

Alleged

According to the report, xenvif_map_frontend_data_rings() can fail after a ring has already been mapped. Its failure handling unmaps the rings but leaves their pointers unchanged, allowing subsequent connection cleanup to reach the same pointers a second time.

Why it matters

Inferred

The issue matters because the cleanup sequence can treat already-unmapped ring pointers as if they were still valid. Clearing those pointers records that the resources are gone and prevents the second unmapping attempt, although the evidence does not describe the possible consequences beyond that attempt.

What to do

Inferred

Administrators should not use this item alone to decide whether a system is patched. It provides no affected or fixed kernel versions, so deployment decisions require matching CVE-2026-99287 or XSA-532 against the relevant kernel or distribution advisory.

Confirmed and still uncertain

Observed

The post identifies the issue as CVE-2026-99287 and XSA-532 and describes the pointer-clearing fix. It lists severity as unknown and gives no CVSS score, affected-version range, fixed-version list, proof of concept, exploitation evidence or demonstrated impact.

What people are saying

Observed

The cve-daily account says the vulnerability has been resolved and invites readers to contribute analysis, proof-of-concept code, mitigations and detections. No independent technical analysis appears in the supplied discussion.

Evolution

Alleged

The reported chain begins with a data-ring mapping failure after a ring is already mapped. The immediate failure path unmaps it, then xenvif_connect_data() enters cleanup, xenvif_disconnect_queue() calls the unmapping routine again, and the new pointer clearing is meant to break that sequence.

Reach

Observed

1 independent groups, 1 updates, and 0 engagements. Observed communities: r/pwnhub.

Technical detail

Alleged

The named routines are xenvif_map_frontend_data_rings(), xenvif_unmap_frontend_data_rings(), xenvif_connect_data() and xenvif_disconnect_queue(). The proposed correction is narrowly scoped: zero the shared-ring, or sring, pointers when they are unmapped so later cleanup does not reuse stale pointer values.

Sources and evidence

Observed

The only substantive supplied item is an automated Reddit CVE-tracker post containing the vulnerability description. The accompanying AutoModerator comment is promotional boilerplate and provides no corroborating technical evidence, so the underlying kernel change, advisory details and release coverage remain unverified within this evidence set.