CVE-2026-80988

What it actually does

In the Linux kernel NTB transport, ntb_transport_tx_enqueue() returns 0 (success) when the queue-pair link is down without taking ownership of the submitted socket buffer. The ntb_netdev path then reports NETDEV_TX_OK and drops its reference, so the skb is never queued and never freed. Each transmit that races a link-down therefore leaks one skb. Repeated races can grow unreclaimed skbuff/slab memory until networking stalls or the host is memory-exhausted. Impact is limited to kernels using ntb_transport/ntb_netdev.

Why it matters to the business

Only Linux hosts that actually use Non-Transparent Bridge interconnects (typical of some clustered or multi-host setups) are in scope; general-purpose servers without NTB are unaffected. A leak during link-down can cause instability or an outage of that interconnect and, in extreme cases, the node. The issue is not in CISA KEV, is not tied to ransomware, has no known in-the-wild use, and has a very low, flat EPSS (0.0022 over 30 days). Treat as a targeted kernel update for NTB-using fleets rather than an organization-wide emergency.

How an attack unfolds

An attacker who can generate transmit traffic on an NTB netdev while the queue-pair link is down—or who can induce link-down races while TX is in flight—causes the kernel to leak one skb per racing frame because enqueue is reported as success without consuming the buffer. Repeating that condition grows kernel memory use until denial of service (OOM, stalled NTB networking, or host instability). This is a local/adjacent resource-exhaustion issue on systems that load NTB transport, not remote code execution. No named threat actors, public exploits, or ransomware campaigns are associated with it, and exploit maturity is none.

How to fix it

Install a Linux kernel that includes the ntb_transport fix: ntb_transport_tx_enqueue() must return -ENOLINK (not 0) when the QP link is down so the caller keeps the buffer, and ntb_netdev must free the skb on non-retryable enqueue failure instead of treating it as NETDEV_TX_OK. Use your distribution or vendor kernel that backports this NTB transport change; no specific upstream version numbers were supplied with this record. There is no complete configuration-only fix. Until patched, keep unused NTB netdevs down, avoid TX during known link-down windows, and do not load NTB modules on hosts that do not need them.

How to confirm the fix worked

Confirm the running kernel includes the NTB TX-enqueue contract change (non-zero/-ENOLINK when the QP is down) via vendor advisory, changelog, or kernel source/patch level. Inventory whether ntb_transport and ntb_netdev are loaded and whether NTB PCI devices exist; hosts with neither are not exposed. After upgrade, bring the QP down while transmitting and verify skb/slab usage does not climb unbounded and that frames are dropped rather than leaked. Re-scan the fleet after rollout.

Typical attack path

1. Find a Linux host that loads ntb_transport/ntb_netdev or has NTB interconnect hardware.
2. Cause or wait for the NTB queue-pair link to go down (flap, peer reset, or equivalent).
3. Submit transmit frames on that NTB netdev so enqueues race the down state.
4. Repeat until unreclaimed skbs exhaust kernel memory and the host or interconnect is denied service.

How to detect it

There is no public exploit and no distinctive malware, file, or network C2 artifact. Hunt on hosts that use NTB: kernel logs for ntb_transport/ntb_netdev around queue-pair link-down, unexplained growth of skbuff-related slabs, and OOM-killer events whose stacks involve NTB or the NTB netdev TX path. Correlate link flaps with rising unreclaimed skbs. Hosts without NTB modules or hardware were not viable targets. Lack of those symptoms does not prove the bug was never hit, only that it did not progress to visible exhaustion.

What your security team should do

• Inventory Linux hosts with NTB hardware or ntb_transport/ntb_netdev loaded and patch those first.
• Deploy vendor/distro kernels that include the ntb_transport -ENOLINK enqueue fix; do not wait for a KEV listing.
• Until patched, disable unused NTB netdevs and watch skb/slab growth around NTB link-down events.
• Do not prioritize this as an emergency outside NTB-using systems: EPSS is ~0.0022, KEV is false, exploit maturity is none.
• Track OS-vendor stable backports and verify the fix is present after kernel rollout.