CVE-2026-45890: Linux Kernel Xen-Netback DoS Vulnerability

CVE-2026-45890 Overview

CVE-2026-45890 is a denial of service vulnerability in the Linux kernel's xen-netback driver. The flaw exists in the backend connect() function, which validates only the upper bound of the multi-queue-num-queues xenbus key but fails to reject a value of zero. A malicious or buggy Xen guest can write "0" to this xenbus key, causing the backend to call vzalloc(array_size(0, sizeof(struct xenvif_queue))). This triggers WARN_ON_ONCE(!size) inside __vmalloc_node_range(). On hosts configured with panic_on_warn=1, the warning escalates to a kernel panic, producing a guest-to-host denial of service.

Critical Impact
An unprivileged Xen guest can crash the host hypervisor kernel when panic_on_warn=1 is set, breaking tenant isolation in multi-tenant virtualization environments.

Affected Products

Linux kernel xen-netback driver (multiple stable branches)
Xen network backend on hosts with panic_on_warn=1
Multi-tenant Xen virtualization deployments running affected kernel versions

Discovery Timeline

2026-05-27 - CVE-2026-45890 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-45890

Vulnerability Analysis

The xen-netback driver supports multi-queue network interfaces between Xen guests and the host backend. During backend connection setup, the driver reads the multi-queue-num-queues xenbus key written by the guest frontend. The Xen network interface specification requires this value to be greater than zero, but the backend connect() function enforced only the upper-bound check against xenvif_max_queues.

When a guest writes "0", requested_num_queues becomes zero and passes validation. The backend then invokes vzalloc(array_size(0, sizeof(struct xenvif_queue))), which reaches __vmalloc_node_range() with a zero size argument. The kernel triggers WARN_ON_ONCE(!size) to flag the invalid allocation request. The fix mirrors the validation already present in xen-blkback, which has rejected zero-queue configurations since its multi-queue support was introduced.

Root Cause

The root cause is missing input validation [CWE-20] on the lower bound of guest-supplied data. The backend trusted the guest to provide a non-zero queue count and only guarded against values exceeding xenvif_max_queues. This is an improper input validation flaw leading to a denial of service condition.

Attack Vector

Exploitation requires control of a Xen guest with write access to its own xenbus keys, which any guest possesses by design. The attacker writes "0" to the multi-queue-num-queues xenbus key before triggering backend connection. When the backend processes the connection request, the zero-sized allocation triggers a kernel warning. If the host is configured with panic_on_warn=1, this warning crashes the host kernel and takes down all co-resident guests.

No authentication beyond normal guest operation is required, and the attack does not require any unusual capability within the guest. See the Linux Kernel Commit ec4859ac for the upstream fix.

Detection Methods for CVE-2026-45890

Indicators of Compromise

Kernel log entries containing WARN_ON_ONCE traces originating from __vmalloc_node_range() with a zero size argument.
Unexpected host kernel panics on Xen dom0 systems running with panic_on_warn=1.
Xenstore audit records showing guest writes of "0" to the multi-queue-num-queues key prior to backend connection.

Detection Strategies

Monitor dom0 kernel ring buffer (dmesg) for warnings referencing vzalloc, __vmalloc_node_range, or xenvif call stacks.
Inspect xenstore values written by guests for out-of-spec entries, particularly zero values on multi-queue-num-queues.
Correlate guest lifecycle events with host kernel warnings to identify suspect guests triggering backend faults.

Monitoring Recommendations

Forward dom0 kernel logs to a centralized logging or SIEM platform and alert on WARN traces from Xen networking paths.
Track host uptime and unexpected reboots across Xen hypervisor fleets to identify panic-on-warn induced crashes.
Audit kernel version inventory across Xen hosts to confirm all dom0 systems are running patched kernels.

How to Mitigate CVE-2026-45890

Immediate Actions Required

Apply the upstream Linux kernel patch that adds a zero-check to the xen-netbackconnect() function on all Xen dom0 hosts.
Inventory kernel versions across Xen hypervisor hosts and prioritize patching systems running with panic_on_warn=1.
Consider temporarily disabling panic_on_warn on Xen dom0 hosts until the patch is deployed, balancing this against local security policy requirements.

Patch Information

The fix has been backported across multiple Linux stable trees. Relevant upstream commits include Linux Kernel Commit 2993e0f, Linux Kernel Commit 654780de, Linux Kernel Commit 6d1dc801, Linux Kernel Commit 787bfa42, Linux Kernel Commit 88b0fced, Linux Kernel Commit ce66d678, Linux Kernel Commit d99f69dd, and Linux Kernel Commit ec4859ac.

Workarounds

Set panic_on_warn=0 in dom0 sysctl configuration to prevent the kernel warning from escalating to a full host panic.
Restrict guest population on affected hypervisors to trusted workloads until patches are applied.
Implement xenstore monitoring tooling that rejects or alerts on out-of-spec values written to multi-queue-num-queues.

bash

# Temporary mitigation: prevent WARN from escalating to panic
sysctl -w kernel.panic_on_warn=0

# Persist across reboots
echo 'kernel.panic_on_warn = 0' >> /etc/sysctl.d/99-xen-cve-2026-45890.conf

# Verify current setting
sysctl kernel.panic_on_warn