CVE-2026-80987

What it actually does

The Linux kernel NTB transport TX path treated oversized transmit buffers as successful completions while invoking the TX handler with a NULL data pointer. ntb_netdev therefore neither freed the associated sk_buff in its completion callback nor followed the enqueue-error path, leaking kernel socket buffers. Repeated oversized transmits grow unreclaimable sk_buff/slab usage until memory is exhausted, producing a host-level denial of service (availability only; no confidentiality or integrity impact).

Why it matters to the business

Only systems that use Linux Non-Transparent Bridge transport or ntb_netdev—typically specialized dual-host, HA cluster, or interconnect hardware—are in scope; general-purpose servers without NTB are not affected. A successful campaign can force kernel memory exhaustion, hangs, or reboots on those interconnects, disrupting failover and cross-host I/O. The issue is not in CISA KEV, has no ransomware association, exploit maturity is none, and EPSS remains low and flat (~0.72% over 30 days), so organization-wide emergency patching is usually unwarranted; patch NTB-equipped, high-availability hosts on a prioritized but non-emergency timeline. The fix has been public for about 20 days.

How an attack unfolds

An attacker who can cause the host to submit a transmit buffer larger than the NTB transport maximum—via ntb_netdev (including locally originated or forwarded frames) or another ntb_transport client—hits ntb_process_tx(), which completes the request as success with a NULL payload. The networking stack keeps the sk_buff, leaking kernel memory. Repeating oversized transmits steadily inflates sk_buff caches until the OOM killer runs or the system becomes unresponsive. This is a resource-leak DoS only; it does not yield code execution or data theft. No named threat actors or campaigns are associated, and there is no public exploit.

How to fix it

Install a Linux kernel that includes the NTB transport fix: ntb_transport_tx_enqueue() must reject oversized buffers with -EMSGSIZE before taking a queue entry so the caller retains the buffer and ntb_netdev can free the skb on that permanent error. Use your distribution’s kernel that contains this upstream ntb_transport change; no per-package version list was published with this advisory. If NTB is not required, unload and blacklist ntb_transport and ntb_netdev and leave NTB modules unbuilt or disabled. There is no complete userspace mitigation while the unpatched transport remains loaded and in active use.

How to confirm the fix worked

Confirm the running kernel changelog or vendor advisory lists the NTB ntb_transport oversized-TX rejection (-EMSGSIZE in ntb_transport_tx_enqueue). Check whether NTB is even present: lsmod for ntb_transport/ntb_netdev and the kernel config for CONFIG_NTB. Hosts without NTB hardware or with those modules unloaded are not exposed. After patching, oversized TX must fail closed without sk_buff growth; under load, watch ntb netdev stats and /proc/slabinfo (skbuff_head_cache and related slabs) for leaks that previously increased without a corresponding free.

Typical attack path

1. Locate a Linux host with NTB hardware and ntb_transport and/or ntb_netdev loaded.
2. Obtain the ability to originate or forward transmit traffic onto that NTB transport or netdev.
3. Submit transmit buffers larger than the NTB payload limit so enqueue is treated as success while sk_buffs are not freed.
4. Repeat oversized transmits to accumulate leaked kernel memory.
5. Wait for slab/sk_buff exhaustion to induce OOM, hang, or reboot (denial of service).

How to detect it

Exploitation leaves no unique success log: the buggy path returned success and leaked silently, and no public exploit or threat-actor tooling is known. Hunt retrospectively on hosts where ntb_transport or ntb_netdev was loaded. Review kernel logs (dmesg, journald, /var/log/kern.log) for OOM killer activity and hung-task traces around heavy NTB transmit. Correlate with memory accounting: sustained growth of skbuff_head_cache or unreclaimable slab on those hosts without a matching traffic-drop or error counter. Netlink/netdev stats and any NTB debugfs counters showing TX completions without corresponding frees are supporting artifacts. Absence of NTB modules makes prior exploitation of this flaw on that host implausible.

• ntb_transport
• ntb_netdev
• module ntb_transport
• module ntb_netdev

What your security team should do

• Inventory hosts with NTB hardware or ntb_transport/ntb_netdev loaded; deprioritize the rest.
• Patch those kernels to a build that rejects oversized NTB TX buffers with -EMSGSIZE, starting with HA/interconnect nodes.
• If NTB is unused, blacklist ntb_transport and ntb_netdev and prevent autoload.
• On remaining unpatched NTB hosts, alert on unexplained sk_buff/slab growth and OOM events.
• Do not treat this as a KEV-style mass emergency: low EPSS, no in-the-wild exploitation, and niche hardware reduce urgency outside NTB-dependent systems.