Bug 2492421 (CVE-2026-52981)

Summary:	CVE-2026-52981 kernel: neigh: let neigh_xmit take skb ownership
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	rhel-process-autobot, watson-tool-maintainers
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in the Linux kernel. The `neigh_xmit` function, when called with an uninitialized neighbor table (such as `NEIGH_ND_TABLE` when IPv6 is disabled), can return an error without properly releasing the allocated `skb` (socket buffer). This can lead to a memory leak, potentially impacting system stability and resource availability.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-06-24 18:11:20 UTC

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.

Comment 1 Mauro Matteo Cascella 2026-06-26 12:02:51 UTC

Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026062441-CVE-2026-52981-dce5@gregkh/T