CVE-2026-100081 · Infrastructure
NO FIX YET
A race in the Linux kernel's Xen network backend frees the multicast address list while transmit and receive processing may still be using it. The sources do not state what an attacker gets beyond this memory-ordering problem.
first public Nov 6, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Systems running the Linux kernel as a Xen host with the xen-netback network backend in use, typically Xen dom0 or driver domains. The sources do not say which kernel versions are affected or whether a default configuration is exposed.
Not affected if no-xen-netback
Who cares linux-kernel, self-hosted, xen, xen-netback
Unknown from the sources.
Unknown from the sources.
In the Linux kernel, the following vulnerability has been resolved:
xen-netback: defer xenvif_mcast_addr_list_free()
In order for the function to legitimately avoid locking/RCU, it needs to run after all TX/RX processing has finished/stopped: Lookups happen from xenvif_start_xmit(), while adds/removes happen from xenvif_tx_action() (called out of xenvif_poll()).
Move the call out of xenvif_disconnect_data() (the call to the function from connect()'s error path doesn't require any cleaning up there), and put it past the synchronization point in backend_disconnect().
This is XSA-527 / CVE-2026-100081.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.