Seven Linux stable kernels shipped on Friday, 6 November 2026, each carrying the same three fixes: 7.3.3, 6.18.62, 6.12.116, 6.6.162, 6.1.192, 5.15.225, and 5.10.274. The 7.3.3 changelog tells the whole story in four commits: three Xen backend fixes and the release commit, nothing else. The flaws are guest-to-host bugs in the in-kernel Xen backends, published as XSA-526, XSA-527, and XSA-528 the same afternoon. If you run Xen hosts, this is a patch-today batch.

Three flaws, one pattern

All three are use-after-free bugs, and all three follow the same shape: a guest triggers a read that races against device teardown, and the backend driver touches memory that has already been freed.

XSA-526 / CVE-2026-100080 — xen-netback, network statistics. The network statistics data is protected by RCU, but when queues are torn down after a failed frontend connection, the data is freed without synchronizing RCU state. A guest that reads the statistics through sysfs in that window can hit freed memory. The fix calls synchronize_net() before freeing the queue data. Linux 4.11 and newer are vulnerable.

XSA-527 / CVE-2026-100081 — xen-netback, multicast addresses. Multicast handling does a lookup early on the transmit path, and that lookup can run in parallel with device teardown. The fix defers freeing the multicast address list until after all transmit and receive processing has stopped. Linux 4.3 and newer are vulnerable.

XSA-528 / CVE-2026-100082 — xen-blkback, I/O statistics. Reads of the block device I/O statistics were never serialized against the freeing of the memory holding them. The fix guards the statistics with a read-write lock. Linux 4.5 and newer are vulnerable.

The advisories agree on impact: the most likely outcome is a driver crash, possibly escalating to a crash of the entire host, which means denial of service for every guest on it. Information leaks cannot be ruled out, and for XSA-527 the advisory adds that privilege escalation cannot be ruled out either, though it calls that very unlikely. These were not embargoed flaws: the advisories note the issues were disclosed in public, which is why the fixes shipped the same day.

Are you affected?

Only one kind of machine is exposed: a Linux host (dom0) running Xen and serving guests through the in-kernel backends. That is the check that matters. A desktop, a laptop, a bare-metal server, or a KVM host does not run xen-netback or xen-blkback, so none of this touches it. Two commands settle it on a suspect host:

BASH
xl info
lsmod | grep -E 'xen_(net|blk)back'

If xl is not installed, you are not running Xen. If the modules are loaded and xl list shows guests, you are in scope. Your distribution will ship the same three commits under its own kernel version number, so check its security tracker for the fixed build rather than waiting for the upstream number to appear.

The patch playbook

  1. Update the dom0 kernel to the fixed build from your distribution. The vulnerable code lives in the host kernel, so patching the guests changes nothing.
  2. Schedule a host reboot. The fixes sit in backend drivers that stay loaded while guests run, so a clean boot is the only way to be sure the old code is gone. Our reboot-after-kernel-patch playbook covers the sequencing: migrate or shut down guests first, patch, reboot, then bring guests back and confirm with uname -r.
  3. Verify after the reboot. Check the running kernel version, confirm xl list shows your guests healthy, and confirm networking and disk I/O work from inside a guest before calling it done.
  4. If you cannot reboot today, the advisories name two real mitigations: switch to a userspace PV backend (the QEMU-based qnic network backend or qdisk block backend), or give each guest its own dedicated driver domain so a crash is contained to one guest's backend. Both are configuration changes, not quick toggles, so plan them rather than improvising on a production host.

A similar synchronized drop happened about a month ago; our seven-kernels-one-Saturday note from October covered it. Stable maintainers batch fixes across every supported branch on purpose, so the version that matters is whichever branch you are on. Still on 7.3, the current stable? The Linux 7.3 upgrade playbook walks through the move.

One more date for the calendar: the Xen advisory list already shows XSA-529 and XSA-530 as pre-released under embargo until 18:00 UTC on 10 November. A second batch is coming next week, so patch this one now and keep the maintenance window warm.

Sources