CVE-2026-52981

What it actually does

This Linux kernel flaw is an sk_buff memory ownership bug in the neighbor transmit path. When neigh_xmit() is called for an unavailable or uninitialized neighbor table, such as an IPv6 neighbor discovery table on a system where IPv6 support is disabled, it can return an error without transmitting, queueing, or freeing the packet buffer. Callers that assume neigh_xmit() always consumes the buffer may then leak kernel memory. Repeated triggering can cause progressive kernel memory exhaustion and denial of service. The issue is not currently associated with code execution, privilege escalation, or data disclosure.

Why it matters to the business

Successful exploitation could degrade or crash Linux systems by exhausting kernel memory, disrupting network services, workloads, appliances, or infrastructure components that depend on affected kernel networking paths. The current public exploitation signal is low: EPSS is low, no known exploited status is reported, it is not listed as used in ransomware, and no mature exploit is known. However, because the Linux kernel is widely deployed, organizations should still remediate through normal kernel patch cycles and prioritize exposed routing, forwarding, container-host, virtualization, and network appliance roles.

How an attack unfolds

An attacker must be able to cause traffic to traverse a kernel networking path that calls neigh_xmit() while the relevant neighbor table is unavailable or unsupported. In a vulnerable kernel, neigh_xmit() may return an error such as address-family-not-supported without taking ownership of the packet buffer. If the caller ignores that return value, the skb is not freed. By repeatedly causing this condition, an attacker can accumulate leaked kernel memory until the system experiences memory pressure, degraded networking, process termination by the OOM killer, or a crash/reboot. Practical exploitation depends heavily on kernel configuration and enabled networking features; systems that do not expose the affected forwarding or encapsulation paths are less likely to be reachable by an attacker.

How to fix it

Apply a vendor kernel update that includes the upstream fix for the neigh_xmit() skb ownership handling issue, commonly referenced by the patch title "neigh: let neigh_xmit take skb ownership." No exact fixed package versions were provided in the input, so use distribution advisories, kernel changelogs, or vendor security bulletins to identify the corrected kernel build for each platform. Where immediate patching is not possible, reduce exposure by disabling unused forwarding, MPLS, tunneling, or encapsulation features; avoiding configurations that call IPv6 neighbor discovery paths when IPv6 support is disabled; rate-limiting untrusted traffic to affected network paths; and monitoring/restarting affected hosts if memory pressure develops. Rebooting can clear leaked memory temporarily but does not remediate the vulnerability.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the neigh_xmit() ownership fix. Validate using package manager metadata, distribution security advisories, kernel changelogs, or source patch presence for the change that ensures neigh_xmit() always transmits, queues, or frees the skb on all return paths. After patching, reboot into the fixed kernel and verify the active kernel version, not only the installed package version. For exposure testing, review kernel configuration and enabled networking features for neighbor transmit users such as forwarding, MPLS, tunneling, or encapsulation paths, especially where address families are disabled or unsupported. In controlled testing only, reproduce the relevant traffic condition before and after patching and confirm kernel memory no longer grows abnormally under repeated failed transmit attempts.

Typical attack path

1. Identify a Linux system or network-facing role using kernel forwarding, encapsulation, MPLS, neighbor-resolution, or similar networking paths that can call neigh_xmit().
2. Determine or assume a configuration where a required neighbor table is unavailable, such as an unsupported or disabled address family.
3. Send traffic that reaches the affected transmit path and causes neigh_xmit() to fail without freeing the skb.
4. Repeat the trigger to leak kernel memory over time.
5. Cause operational impact through memory exhaustion, network degradation, OOM-killer activity, service disruption, or system crash.

How to detect it

There are no public, CVE-specific indicators that reliably prove exploitation. Detection should focus on symptoms and contextual evidence: kernel memory steadily increasing without a matching userspace process, OOM-killer activity, network service degradation, soft lockups, panics, or reboots after bursts of traffic through forwarding, MPLS, tunneling, or encapsulation paths. Review kernel logs, system journals, hypervisor or appliance logs, flow records, firewall logs, and network telemetry for repeated traffic patterns preceding memory pressure. On Linux, examine dmesg, journalctl, /var/log/kern.log, /var/log/messages, and metrics from node exporters or EDR agents for sustained slab/skbuff growth, OOM events, and resets. If packet captures or flow logs are available, correlate the onset of memory growth with high-rate traffic to paths that could invoke neighbor resolution for disabled or unsupported address families. Absence of explicit log messages does not rule out exploitation because the vulnerable path is not expected to emit a unique error by default.

What your security team should do

• Inventory Linux systems that perform routing, forwarding, encapsulation, MPLS, container networking, virtualization networking, or network-appliance functions, and prioritize them for kernel updates.
• Patch affected systems through the appropriate distribution or appliance vendor kernel update channel and reboot into the fixed kernel.
• Because no KEV listing, ransomware association, or mature public exploit is currently known, handle broad workstation/server fleets through normal vulnerability management SLAs, while prioritizing internet-facing or untrusted-traffic network roles.
• Review configurations where IPv6 or other address families are disabled while networking features may still reference their neighbor tables.
• Add monitoring for abnormal kernel memory growth, OOM-killer events, network stack instability, and unexplained host reboots on systems awaiting patches.
• If patching must be delayed, reduce attack surface by disabling unused MPLS, forwarding, tunneling, or encapsulation features and rate-limit untrusted traffic to susceptible paths.
• Track vendor advisories for exact fixed kernel package versions, as fixed versions were not provided in the input.