Skip to main content

Linux Kernel CVE-2025-38413

MEDIUM
2025-07-25 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Information Disclosure Linux 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

Local vector and low privilege confirmed by kernel driver context; AF_XDP configuration requirement affects exposure but not per-exploit complexity once present; availability-only impact consistent with kernel crash from boundary violation.

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:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
6.1 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H
Red Hat
6.1 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

2
Analysis Generated
Jul 30, 2026 - 08:53 vuln.today
CVE Published
Jul 25, 2025 - 14:15 nvd
MEDIUM 5.5

DescriptionNVD

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

virtio-net: xsk: rx: fix the frame's length check

When calling buf_to_xdp, the len argument is the frame data's length without virtio header's length (vi->hdr_len). We check that len with

xsk_pool_get_rx_frame_size() + vi->hdr_len

to ensure the provided len does not larger than the allocated chunk size. The additional vi->hdr_len is because in virtnet_add_recvbuf_xsk, we use part of XDP_PACKET_HEADROOM for virtio header and ask the vhost to start placing data from

hard_start + XDP_PACKET_HEADROOM - vi->hdr_len not hard_start + XDP_PACKET_HEADROOM

But the first buffer has virtio_header, so the maximum frame's length in the first buffer can only be

xsk_pool_get_rx_frame_size() not xsk_pool_get_rx_frame_size() + vi->hdr_len

like in the current check.

This commit adds an additional argument to buf_to_xdp differentiate between the first buffer and other ones to correctly calculate the maximum frame's length.

AnalysisAI

Incorrect frame length validation in the Linux kernel's virtio-net XDP socket (AF_XDP/XSK) receive path allows a local low-privileged attacker to trigger a kernel availability failure. The buf_to_xdp function incorrectly permits the first receive buffer's frame data to reach xsk_pool_get_rx_frame_size() + vi->hdr_len bytes, when the virtio header already occupies space within that first buffer, capping valid data at xsk_pool_get_rx_frame_size(). No public exploit code has been identified and EPSS sits at the 5th percentile, reflecting low real-world exploitation probability at this time.

Technical ContextAI

The vulnerability resides in the Linux kernel virtio-net driver's XDP socket (AF_XDP) receive path, specifically in the buf_to_xdp helper. In virtnet_add_recvbuf_xsk, part of XDP_PACKET_HEADROOM is carved out for the virtio header (vi->hdr_len), causing the vhost to begin placing packet data at hard_start + XDP_PACKET_HEADROOM - vi->hdr_len. Because the first receive buffer includes the virtio header itself, the maximum usable frame data in that buffer is bounded by xsk_pool_get_rx_frame_size() alone. The existing check against xsk_pool_get_rx_frame_size() + vi->hdr_len incorrectly inflates this limit, producing an off-by-hdr_len boundary error. Subsequent buffers do not carry the virtio header and the larger limit is valid for them. The fix introduces a boolean argument to buf_to_xdp distinguishing first-buffer from subsequent-buffer calls. CWE is not assigned by NVD; the root cause class is an incorrect bounds check (analogous to CWE-131 / CWE-823). Affected CPE: cpe:2.3:o:linux:linux_kernel:* across multiple stable branches and explicitly 6.16-rc1 through 6.16-rc4.

RemediationAI

Apply the upstream kernel fixes published to the stable tree: commit 5177373c31318c3c6a190383bfd232e6cf565c36 (https://git.kernel.org/stable/c/5177373c31318c3c6a190383bfd232e6cf565c36), commit 6013bb6bc24c2cac3f45b37a15b71b232a5b00ff (https://git.kernel.org/stable/c/6013bb6bc24c2cac3f45b37a15b71b232a5b00ff), and commit 892f6ed9a4a38bb3360fdff091b9241cfa105b61 (https://git.kernel.org/stable/c/892f6ed9a4a38bb3360fdff091b9241cfa105b61). These are commit-level references; released patched version tags per stable branch are not independently confirmed from available data - verify against kernel.org stable release notes. As a targeted workaround with no patch applied, disabling AF_XDP socket usage on virtio-net interfaces (avoid binding XSK sockets to those interfaces) eliminates the vulnerable code path entirely; trade-off is loss of zero-copy XDP receive performance that AF_XDP provides. Standard virtio-net operation without AF_XDP is unaffected and no action is needed on those systems.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
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

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
Image SLES-Azure-3P Image SLES-Azure-Basic Image SLES-Azure-Standard Image SLES-BYOS-Azure Image SLES-BYOS-EC2 Image SLES-BYOS-GCE Image SLES-CHOST-BYOS-Aliyun Image SLES-CHOST-BYOS-Azure Image SLES-CHOST-BYOS-EC2 Image SLES-CHOST-BYOS-GCE Image SLES-CHOST-BYOS-GDC Image SLES-CHOST-BYOS-SAP-CCloud Image SLES-EC2 Image SLES-EC2-ECS Image SLES-GCE Image SLES-GCE-3P Image SLES-Hardened-BYOS-Azure Image SLES-Hardened-BYOS-EC2 Image SLES-Hardened-BYOS-GCE Image SLES-SAPCAL-Azure Image SLES-SAPCAL-EC2 Image SLES-SAPCAL-GCE Affected
Image SLES-SAP-Azure Image SLES-SAP-Azure-3P Image SLES-SAP-BYOS-Azure Image SLES-SAP-BYOS-EC2 Image SLES-SAP-BYOS-GCE Image SLES-SAP-EC2 Image SLES-SAP-GCE Image SLES-SAP-GCE-3P Affected
SUSE Linux Enterprise High Availability Extension 16.0 Fixed
SUSE Linux Enterprise Server 16.0 Fixed
SUSE Linux Enterprise Server 16.1 Fixed

Share

CVE-2025-38413 vulnerability details – vuln.today
Back

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