KernelScan.io

HIGH Introduced in 4.18

qede TpaFragment Deref

CVE-2026-89511

CVSS 7.5 / 10.0 NVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

KernelScan AI5.9MEDIUM

01

In the Linux kernel, the following vulnerability has been resolved: qede: Fix NULL pointer dereference in TPA fragment processing Under memory pressure, the qede driver encounters NULL pointer dereferences when processing TPA continuation fragments. Commit 8a8633978b84 ("qede: Add build_skb() support.") accidentally dropped the assignment of tpa_info->buffer.data in qede_tpa_start(). When memory pressure causes an SKB allocation failure in qede_tpa_start(), the driver sets tpa_start_fail = true and attempts to recycle the physical page later in qede_tpa_end() via qede_reuse_page(). However, because buffer.data was left uninitialized (NULL), qede_reuse_page() pushes a "ghost" BD (valid DMA mapping but NULL data pointer) back into the active Rx ring. The next time the hardware uses this ring slot, it passes a NULL page to qede_fill_frag_skb(), causing a kernel panic. Example crash from production system: BUG: unable to handle kernel NULL pointer dereference at 0x8 RIP: qede_fill_frag_skb+0x96/0x430 [qede] Call Trace: qede_rx_int+0xb06/0x1de0 qede_poll+0x2f4/0x6c0 __napi_poll+0x2d/0x130 Fix the root cause by restoring the tpa_info->buffer.data assignment in qede_tpa_start(), ensuring valid pages are correctly tracked and recycled. Additionally, update the stale comment for struct qede_agg_info::buffer to reflect its current usage.

02

Engine v0.6.0

Risk summary

A NULL pointer dereference in the qede network driver's TPA fragment processing path can be triggered under memory pressure, causing a kernel panic. The bug is reachable by an attacker on the network who can send packets to a host using a QLogic FastLinQ NIC, requiring no privileges. The impact is denial of service.

Affecteddrivers/net/ethernet/qlogic/qede/qede_fp.c (qede)

Vulnerability analysis

When the driver starts hardware packet aggregation and a memory allocation fails under pressure, the cleanup path tries to recycle the receive page back into the ring, but a prior change accidentally left the page reference uninitialized. The recycled descriptor therefore carries a valid DMA mapping with no associated page, and the next time the hardware fills that ring slot the driver dereferences the empty pointer while handling the continuation fragment, causing a kernel panic. The fix restores the missing assignment so the page reference is always set before recycling, keeping the ring slot valid even when allocation fails. The vulnerable path is reached whenever the driver processes incoming aggregated packets on the affected network interface, so any network peer sending traffic to the host can trigger it once the system is under memory pressure.

03

BranchIntroducedFixed inPatch commit
5.104.185.10.270e2214e279315
5.154.185.15.221dd8bc0a9d87d
6.14.186.1.188fa7c9bd2c4a8
6.124.186.12.1097f911e208b3c
6.184.186.18.502a952fb1b20d
6.64.186.6.157a5e1fdc126ab
7.24.187.2.4f5c8619ccbd7
mainline4.187.306aa3d26327f
cip/5.104.185.10.271-cip78e2214e279315
cip/6.14.186.1.189-cip61fa7c9bd2c4a8
cip/6.1-rt4.186.1.189-cip61-rt32fa7c9bd2c4a8
cip/6.124.186.12.111-cip327f911e208b3c

04

State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.

CIP treeState
cip/6.12Fixed in 6.12.111-cip32
cip/6.1Fixed in 6.1.189-cip61
cip/6.1-rtFixed in 6.1.189-cip61-rt32
cip/5.10Fixed in 5.10.271-cip78
cip/5.10-rtAffected — no CIP fix yet (latest 5.10.268-cip77-rt34)
cip/4.19Affected — no CIP fix yet (latest 4.19.325-cip136)
cip/4.19-rtAffected — no CIP fix yet (latest 4.19.325-cip136-rt50)