CVE-2026-89511

What it actually does

The Linux kernel qede (QLogic/Marvell FastLinQ) Ethernet driver can dereference a NULL pointer while processing TPA (TCP Packet Aggregation) continuation fragments. After an SKB allocation failure under memory pressure, tpa_info->buffer.data is left NULL, so qede_reuse_page() recycles a ghost buffer descriptor (valid DMA mapping, NULL data) onto the active Rx ring. The next hardware fill of that slot passes a NULL page into qede_fill_frag_skb(), causing an unrecoverable kernel oops/panic on the receive/NAPI path. Impact is availability only (host crash); there is no indicated confidentiality or integrity compromise.

Why it matters to the business

Systems using qede-backed NICs can suffer sudden, unplanned kernel panics and full host outages when receive-side TPA runs during memory pressure, interrupting workloads, clustering, and network services on those servers. The issue is not listed in CISA KEV, is not associated with ransomware, and has low EPSS (~0.007) with a flat 30-day trend and no public exploit maturity, so mass opportunistic exploitation is unlikely; however, any production Linux fleet with FastLinQ adapters remains exposed to availability loss until patched. Published about 32 days ago, so patch windows should already be in progress for affected kernels.

How an attack unfolds

An unauthenticated network attacker, or any condition that drives qede TPA while the host is short on memory, can induce the faulty recycle path. Traffic that the NIC aggregates as TPA (typical TCP flows) combined with SKB allocation failure in qede_tpa_start() leaves a NULL data pointer on the Rx ring. Subsequent fragments processed by qede_rx_int/qede_poll hit qede_fill_frag_skb() with a NULL page and panic the kernel. No privilege, user interaction, or special credentials are required per the CVSS vector; success depends on the qede driver being in use, TPA being active, and memory pressure causing the allocation failure. No named threat actors or in-the-wild campaigns are associated with this CVE.

How to fix it

Apply the upstream Linux kernel fix that restores the tpa_info->buffer.data assignment in qede_tpa_start() so pages are tracked and recycled correctly, and take the corresponding stable/distribution kernel update as soon as your vendor publishes it. If a patched kernel is not yet available, reduce exposure by avoiding qede TPA/LRO-style aggregation where the driver or ethtool/module options allow it, keep memory pressure off production qede hosts, or temporarily move critical traffic off FastLinQ adapters. Reboot onto the patched kernel; this is not a userspace-only fix. Confirm the exact package version with your distro kernel changelog (no per-package fixed versions were supplied with this record).

How to confirm the fix worked

Confirm the running kernel includes the qede TPA start buffer.data restoration (distro advisory, kernel changelog, or inspection of qede_tpa_start() in the built module). Verify the loaded qede module matches the patched kernel (modinfo qede; uname -r). After upgrade, exercise TCP receive load on qede interfaces under constrained memory in a test environment and confirm no oops in qede_fill_frag_skb / qede_rx_int / qede_poll. Inventory remaining unpatched hosts with qede bound to interfaces (lsmod, sysfs driver links, ethtool -i).

Typical attack path

1. Identify Linux hosts whose NICs are bound to the qede driver (QLogic/Marvell FastLinQ).
2. Generate or wait for memory pressure so SKB allocation in qede_tpa_start() can fail.
3. Send or induce TCP traffic that the adapter processes via TPA start/continuation/end.
4. Trigger the failed TPA start so a ghost BD (NULL buffer.data) is reused onto the Rx ring.
5. Cause a later TPA fragment to be processed on that ring slot, hitting qede_fill_frag_skb() with a NULL page.
6. Kernel oops/panic on the NAPI/Rx path takes the host down (denial of service).

How to detect it

Hunt historical kernel logs and crash dumps for oopses on the qede receive path rather than expecting C2 or malware artifacts. Primary sources: dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, kdump/vmcore, ABRT/kdump reports, and panic consoles. Look for RIP in qede_fill_frag_skb with a call trace through qede_rx_int, qede_poll, and __napi_poll, and a NULL pointer dereference (commonly at a small offset such as 0x8). Correlate timestamps with memory pressure (OOM, reclaim, allocation failures) and heavy TCP receive on qede interfaces. No named APT tooling or ransomware notes apply; absence of these traces does not prove the host was never exposed, only that this particular panic may not have fired.

• RIP: qede_fill_frag_skb
• qede_fill_frag_skb+
• qede_rx_int+
• qede_poll+
• [qede]
• unable to handle kernel NULL pointer dereference at 0x8
• BUG: unable to handle kernel NULL pointer dereference
• Call Trace: qede_rx_int
• tpa_start_fail
• qede_reuse_page

What your security team should do

• Inventory all Linux hosts with the qede driver loaded or FastLinQ NICs in use and prioritize kernel upgrades there.
• Track distro/stable kernel advisories for this fix and patch within the normal high-severity availability SLA; KEV is not set so CISA due-date urgency does not apply.
• Until patched, monitor for qede oopses and consider disabling TPA/LRO on qede if operationally acceptable.
• Treat recurrence of this panic as a reliability incident, not as evidence of targeted intrusion, unless other independent IOCs appear.
• Keep EPSS and KEV under review; current exploitation likelihood is low and there is no ransomware or named-actor overlay.