Skip to main content

Linux Kernel EUVDEUVD-2026-38849

| CVE-2026-52981 HIGH
Memory Leak (CWE-401)
2026-06-24 Linux GHSA-36qf-2q77-7jh9
High
Disputed · 7.5 Vendor: Linux
Share

Severity by source

Sources disagree (Low–High)
Vendor (Linux) PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
3.7 LOW

Network-reachable but depends on non-default MPLS-plus-IPv6-disabled config so AC:H; only a gradual per-packet skb leak yields availability impact, hence A:L and C/I:N.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
4.0 AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
SUSE
3.7 LOW
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
Red Hat
5.5 MEDIUM
qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

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

Lifecycle Timeline

5
Analysis Generated
Jun 28, 2026 - 08:40 vuln.today
CVSS changed
Jun 28, 2026 - 08:22 NVD
7.5 (HIGH)
Patch available
Jun 24, 2026 - 18:02 EUVD
CVE Published
Jun 24, 2026 - 16:28 cve.org
HIGH 7.5
CVE Published
Jun 24, 2026 - 16:28 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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

neigh: let neigh_xmit take skb ownership

neigh_xmit always releases the skb, except when no neighbour table is found. But even the first added user of neigh_xmit (mpls) relied on neigh_xmit to release the skb (or queue it for tx).

sashiko reported: If neigh_xmit() is called with an uninitialized neighbor table (for example, NEIGH_ND_TABLE when IPv6 is disabled), it returns -EAFNOSUPPORT and bypasses its internal out_kfree_skb error path. Because the return value of neigh_xmit() is ignored here, does this leak the SKB?

Assume full ownership and remove the last code path that doesn't xmit or free skb.

AnalysisAI

Memory exhaustion in the Linux kernel networking stack stems from a socket buffer (SKB) leak in neigh_xmit(): when the function is called against an uninitialized neighbour table - for example NEIGH_ND_TABLE while IPv6 is disabled - it returns -EAFNOSUPPORT and bypasses its out_kfree_skb path, leaking the packet buffer because callers (originally MPLS) rely on neigh_xmit() to take ownership of the skb. Repeated triggering slowly exhausts kernel memory, leading to denial of service (CVSS 7.5, A:H). There is no public exploit identified at time of analysis, and EPSS is low (0.19%, 9th percentile); the upstream fix makes neigh_xmit() assume full ownership and free the skb on every path.

Technical ContextAI

The flaw lives in the kernel's neighbour subsystem (net/core/neighbour.c), which resolves L2 addresses (ARP for IPv4, NDISC/ND for IPv6) before transmitting frames. neigh_xmit() is a helper used by upper layers - notably MPLS (net/mpls) and lwtunnel encapsulation - to hand a packet to a neighbour for transmission; by contract it either queues/transmits the skb or frees it. The bug is a resource-management / memory-leak class issue (functionally CWE-401 'Missing Release of Memory', though NVD lists CWE as N/A): the error branch for a missing/uninitialized neigh table (NEIGH_ND_TABLE with IPv6 compiled out or disabled) returns an error code without reaching the out_kfree_skb cleanup, and callers ignore the return value, so the skb is never freed. Affected CPE is cpe:2.3:a:linux:linux across a range of versions; the reporting tag 'Information Disclosure' is inconsistent with the actual impact, which is memory leak / availability.

RemediationAI

Upgrade to a kernel that includes the fix: Vendor-released patch - 6.1.175, 6.6.141, 6.12.91, 6.18.33, 7.0.10, or 7.1 (or your distribution's backported equivalent). The fix makes neigh_xmit() assume full ownership of the skb so every path either transmits, queues, or frees it. The relevant stable commits are at https://git.kernel.org/stable/c/8a89054a1ec0767aec25ed2bbac933da6ba3cf5a and the other listed git.kernel.org references. If immediate patching is not possible, the leak only occurs on the uninitialized-neigh-table path, so a concrete compensating control is to avoid the triggering configuration - keep IPv6 enabled where NEIGH_ND_TABLE is used, and/or disable MPLS forwarding (do not load the mpls_router module / unset net.mpls.platform_labels) if it is not required; trade-off is loss of MPLS functionality on those hosts. Monitor kernel slab/SKB memory (e.g. /proc/slabinfo, kmalloc caches) to detect leakage in the interim.

Vendor StatusVendor

SUSE

Severity: Low
Product Status
Image SLES15-SP7-Azure-3P Image SLES15-SP7-Azure-Basic Image SLES15-SP7-Azure-Standard Image SLES15-SP7-HPC-Azure Affected
Image SLES15-SP7-BYOS-Azure Image SLES15-SP7-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-Aliyun Image SLES15-SP7-CHOST-BYOS-Azure Image SLES15-SP7-CHOST-BYOS-EC2 Image SLES15-SP7-CHOST-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-GDC Image SLES15-SP7-CHOST-BYOS-SAP-CCloud Image SLES15-SP7-EC2 Image SLES15-SP7-EC2-ECS-HVM Image SLES15-SP7-GCE Image SLES15-SP7-HPC-BYOS-Azure Image SLES15-SP7-HPC-BYOS-EC2 Image SLES15-SP7-HPC-BYOS-GCE Image SLES15-SP7-Hardened-BYOS-Azure Image SLES15-SP7-Hardened-BYOS-EC2 Image SLES15-SP7-Hardened-BYOS-GCE Image SLES15-SP7-SAPCAL-Azure Image SLES15-SP7-SAPCAL-EC2 Image SLES15-SP7-SAPCAL-GCE Affected
Image SLES15-SP7-SAP-Azure Image SLES15-SP7-SAP-Azure-3P Image SLES15-SP7-SAP-BYOS-Azure Image SLES15-SP7-SAP-BYOS-EC2 Image SLES15-SP7-SAP-BYOS-GCE Image SLES15-SP7-SAP-EC2 Image SLES15-SP7-SAP-GCE Image SLES15-SP7-SAP-Hardened-Azure Image SLES15-SP7-SAP-Hardened-BYOS-Azure Image SLES15-SP7-SAP-Hardened-BYOS-EC2 Image SLES15-SP7-SAP-Hardened-BYOS-GCE Image SLES15-SP7-SAP-Hardened-GCE Affected
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed

Share

EUVD-2026-38849 vulnerability details – vuln.today

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