CVE-2026-45890

What it actually does

This flaw affects the Linux kernel Xen network backend driver (xen-netback). A privileged or malicious Xen guest can publish an invalid frontend configuration by setting the xenbus key "multi-queue-num-queues" to 0. The backend validates only the upper bound and fails to reject zero, allowing a zero-sized allocation path through vzalloc(array_size(0, sizeof(struct xenvif_queue))). That triggers a kernel WARN_ON_ONCE in the vmalloc path. On hosts configured with panic_on_warn=1, the warning becomes a kernel panic, causing host-level denial of service and potentially impacting multiple virtual machines on the same Xen host.

Why it matters to the business

The main risk is operational disruption: a guest VM can crash the Xen host if the host is configured to panic on kernel warnings, potentially taking down other workloads on the same physical server. The CVSS score is moderate and EPSS is currently very low, and there is no known KEV listing or ransomware association, but the issue is important for Xen hosting, private cloud, and virtualization platforms because the blast radius can extend beyond the attacking guest.

How an attack unfolds

An attacker first needs control of, or sufficient privileges within, a Xen guest that has a paravirtualized network interface backed by xen-netback on the host. The attacker modifies the XenStore/xenbus frontend configuration for that virtual network device and writes the value "0" to the "multi-queue-num-queues" key. When the backend processes the connection request, it accepts the zero queue count because the vulnerable validation only checks whether the value exceeds the maximum. The backend then attempts to allocate an array for zero queues, reaching a kernel warning in the vmalloc allocator. If the host has panic_on_warn enabled, the warning is escalated into a kernel panic, crashing the host and interrupting guest workloads. If panic_on_warn is not enabled, exploitation may still generate kernel warnings and backend errors but is less likely to produce a full host outage.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the xen-netback fix rejecting zero queue counts. No specific fixed version was provided in the input, so use the relevant distribution, hypervisor platform, or kernel vendor advisory to identify the patched package for each maintained kernel stream. Where immediate patching is not possible, reduce risk by disabling panic_on_warn where operationally acceptable, restricting administrative access inside guest VMs, limiting untrusted tenant access to Xen guests, monitoring XenStore manipulation, and isolating high-risk guests onto hosts where a guest-triggered host panic has reduced blast radius. These mitigations reduce exposure but do not replace the kernel fix.

How to confirm the fix worked

Confirm that the running kernel package includes the xen-netback patch that rejects "multi-queue-num-queues=0". Validate by checking vendor changelogs or source patches for a lower-bound check requiring requested_num_queues to be greater than zero in the xen-netback connection path. On hosts, confirm the active kernel version after reboot using uname or package inventory and verify that the patched kernel is booted, not merely installed. Also check whether /proc/sys/kernel/panic_on_warn is set to 1; if it is, vulnerable hosts have a higher denial-of-service impact. In a controlled non-production environment only, a negative test can attempt to present a zero queue count from a test guest and confirm that the backend rejects it without a kernel warning or panic.

Typical attack path

1. Gain administrative or sufficient control inside a Xen guest VM with a paravirtualized network device.
2. Locate the XenStore/xenbus path for the guest network frontend configuration.
3. Write an invalid value of 0 to the "multi-queue-num-queues" key.
4. Trigger or wait for the xen-netback connection handling path to process the frontend configuration.
5. Cause xen-netback to attempt a zero-sized queue allocation and trigger a kernel warning.
6. On hosts with panic_on_warn=1, force a host kernel panic and denial of service.

How to detect it

Look for evidence of kernel warnings or host crashes associated with xen-netback shortly after guest network connection or reconnection events. Relevant log sources include the host kernel ring buffer, persistent system journal, syslog/kern.log, Xen toolstack logs, hypervisor management logs, and crash dump records such as kdump/vmcore metadata. Search for warnings involving xen-netback, zero-sized vmalloc/vzalloc allocation, __vmalloc_node_range, and the xenbus key "multi-queue-num-queues". Also review XenStore activity, if audited, for guest writes setting "multi-queue-num-queues" to "0". If the host rebooted unexpectedly, correlate the reboot time with guest network device changes, VM lifecycle events, and kernel panic records. Because this vulnerability produces denial-of-service rather than code execution, there may be no persistent malware artifact; detection is primarily based on kernel panic traces, warning logs, and suspicious XenStore configuration changes.

• multi-queue-num-queues
• multi-queue-num-queues = 0
• multi-queue-num-queues=0
• xen-netback
• __vmalloc_node_range
• WARN_ON_ONCE(!size)
• panic_on_warn
• Kernel panic - not syncing
• vzalloc
• vmalloc
• xenbus
• /proc/sys/kernel/panic_on_warn
• /sys/module/xen_netback

What your security team should do

• Prioritize patching Xen hosts or Linux kernels that run xen-netback for guest networking, especially multi-tenant or externally managed guest environments.
• Inventory Xen hosts and identify systems with /proc/sys/kernel/panic_on_warn set to 1, because those systems are more susceptible to host-wide denial of service.
• Review guest administration boundaries and restrict which users or tenants can modify XenStore/xenbus frontend configuration values.
• Monitor kernel logs and hypervisor logs for xen-netback warnings, vmalloc zero-size allocation warnings, and guest network reconnect anomalies.
• If patching is delayed, consider temporarily disabling panic_on_warn where consistent with operational and security policy, and isolate untrusted guests from critical workload hosts.
• Track vendor kernel advisories for exact fixed package versions and confirm patched kernels are actually booted after maintenance windows.