The EPSS score of 0.00457 badly undersells this vulnerability. A double-free in a kernel network driver's transmit path is a high-value exploitation target regardless of how rarely the failure condition appears to fire.
The bug lives in rtase_tx_clear_range(), which conflates two distinct responsibilities: clearing DMA descriptors and releasing the skb. When processing a multi-fragment packet, the function releases the skb when clearing the last-fragment slot, then falls through to a common error label that releases it again. Every failure of head-buffer DMA mapping after fragment mapping succeeds produces a double-free.
This isn't an exotic trigger condition. Multi-fragment packets are routine in high-throughput environments, and DMA resource contention is a realistic stress state. The tx_dropped counter incrementing twice per failure could serve as a detection signature, though most production systems don't instrument per-driver metrics at that granularity. SLUB_DEBUG or KASAN would catch this, but those aren't enabled in typical production kernels.
The exploitation profile is concerning. The skb layer's allocator is well-studied, and network packets provide user-controlled input that makes heap layout timing more predictable. The rtase driver's use of a separate TX ring creates a distinct allocation context that an attacker could potentially groom. A successful exploit would give controlled heap corruption in kernel context — not merely a crash, but a foundation for privilege escalation.
The blast radius extends beyond the host. Realtek PCIe Ethernet controllers ship in switches, routers, and embedded systems that sit at infrastructure chokepoints. This driver hasn't received the same scrutiny as Intel or Broadcom drivers, and the fix pattern (return early before the fallthrough error label) is documented in kernel history — suggesting institutional forgetting rather than novel failure.
Prioritize this regardless of the EPSS number. The trigger condition is the baseline operational state of any system under network load, and the exploitation chain leads to kernel-level code execution on hardware that often lives outside container namespaces.