Skip to main content

Linux Kernel EUVDEUVD-2026-32356

| CVE-2026-45890 MEDIUM
2026-05-27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-jc43-3m97-6p35
Linux Information Disclosure Red Hat Suse
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
5.5 MEDIUM

Guest writes xenbus key (local vector, low privilege); no confidentiality or integrity impact; host availability high only with panic_on_warn=1.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H
SUSE
6.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 25, 2026 - 21:32 vuln.today
CVSS changed
Jun 25, 2026 - 21:22 NVD
5.5 (MEDIUM)
Patch available
May 27, 2026 - 19:46 EUVD
CVE Published
May 27, 2026 - 14:17 nvd
UNKNOWN (no severity yet)
CVE Published
May 27, 2026 - 14:17 nvd
MEDIUM 5.5

DescriptionNVD

In the Linux kernel, the following vulnerability has been resolved:

xen-netback: reject zero-queue configuration from guest

A malicious or buggy Xen guest can write "0" to the xenbus key "multi-queue-num-queues". The connect() function in the backend only validates the upper bound (requested_num_queues > xenvif_max_queues) but not zero, allowing requested_num_queues=0 to reach vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers WARN_ON_ONCE(!size) in __vmalloc_node_range().

On systems with panic_on_warn=1, this allows a guest-to-host denial of service.

The Xen network interface specification requires the queue count to be "greater than zero".

Add a zero check to match the validation already present in xen-blkback, which has included this guard since its multi-queue support was added.

AnalysisAI

Guest-to-host denial of service in the Linux kernel's xen-netback driver allows a malicious or buggy Xen guest to crash the hypervisor host by writing "0" to the xenbus key multi-queue-num-queues. The connect() function validates only the upper bound of requested_num_queues, permitting a zero value to reach vzalloc(array_size(0, ...)), which triggers WARN_ON_ONCE in __vmalloc_node_range(); on hosts with panic_on_warn=1 this escalates to a full kernel panic. No public exploit exists and EPSS is 0.02% (7th percentile), consistent with a narrow Xen-specific attack surface, but the guest-controlled code path is trivial to trigger and vendor patches have been backported across seven stable kernel series, confirming the impact is real.

Technical ContextAI

The xen-netback kernel module implements the backend driver for the Xen paravirtualized network interface, processing xenbus configuration written by guest VMs. When a guest initializes multi-queue networking, it writes the desired queue count to the xenbus key multi-queue-num-queues; the backend's connect() function reads this value and allocates a queue array via vzalloc(array_size(requested_num_queues, sizeof(struct xenvif_queue))). The Xen network interface specification mandates this value be greater than zero, and xen-blkback (the block device equivalent) already enforces this invariant, but xen-netback lacked the corresponding guard. Passing zero to array_size() produces zero, and vzalloc(0) triggers WARN_ON_ONCE(!size) inside __vmalloc_node_range(). The root cause is improper input validation (functionally equivalent to CWE-20) on a trust boundary between the guest and the host kernel - no CWE was formally assigned in NVD. Affected CPE: cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* from the commit introducing multi-queue xen-netback support (8d3d53b3e433, approximately Linux 3.16) through the patch commits listed in EUVD-2026-32356.

RemediationAI

Upgrade to a patched Linux kernel: 5.10.252, 5.15.202, 6.1.165, 6.6.128, 6.12.75, 6.18.14, 6.19.4, or 7.0, as confirmed by EUVD-2026-32356 and kernel.org stable commits. Patch commits for each stable branch are available at the git.kernel.org stable URLs in the references section. If an immediate kernel upgrade is not feasible, the most targeted compensating control is to ensure panic_on_warn=1 is NOT set on Xen host kernels, which removes the escalation path from WARN_ON to kernel panic; without this flag the host continues running with only a kernel warning log entry. Be aware that removing panic_on_warn=1 reduces host auditability for kernel integrity assertions and may conflict with hardening baselines. A second compensating control is to restrict which guest VMs are permitted to configure multi-queue networking via xenbus ACLs, limiting exposure to trusted guests only; however, this requires careful xenstore permission management and does not eliminate the WARN_ON trigger entirely. NVD advisory: https://nvd.nist.gov/vuln/detail/CVE-2026-45890.

Same technique Information Disclosure

View all
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8
CVE-2023-7028 CRITICAL POC
10.0
CVE-2017-0213 HIGH POC
7.3

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Performance Computing 15 SP7 Affected

Share

EUVD-2026-32356 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy