CVE-2026-98558: net: flush skb_defer_nodes in dev_cpu_dead()
In the Linux kernel, the following vulnerability has been resolved:
net: flush skbdefernodes in devcpudead()
When a CPU goes offline, devcpudead() drains its softnet queues (completionqueue, outputqueue, polllist, processqueue, and inputpktqueue), but leaves nethotdata.skbdefernodes untouched.
If oldcpu goes offline while holding pending skbs in its skbdefernodes lists (e.g. below the sysctlskbdefermax >> 1 IPI threshold, or if the IPI races with CPU teardown), those skbs remain stranded until oldcpu is brought back online. If any of these skbs hold pagepool fragments, pagepooldestroy() will stall indefinitely waiting for inflight pages to be returned when a netdev or driver is torn down while oldcpu is offline.
Additionally, if smpcallfunctionsingleasync() fails in kickdeferlistpurge() because the target CPU went offline, reset deferipischeduled to 0 so future IPI kicks are not blocked when the CPU comes back online.
Also, if oldcpu was the last online CPU on its NUMA node, drain that node's slot across all CPUs so no skbs deferred from that node remain stranded on idle remote CPUs (or if the node itself is subsequently offlined).
Finally, in skbattemptdeferfree(), re-check cpuonline(cpu) and whether the caller migrated CPUs after llistadd(), flushing the node list if so, to close the preemption TOCTOU race against CPU/node teardown.
Affected Software
Event History
Frequently Asked Questions
What conditions are needed for this issue to cause an operational impact?
A CPU must go offline while it has pending skbs in its skb_defer_nodes lists. The impact becomes visible when those skbs hold page_pool fragments and a network device or driver is torn down while that CPU remains offline, causing page_pool_destroy() to wait indefinitely for inflight pages.
Are all deferred skbs necessarily stranded when a CPU is offlined?
No. The affected case includes deferred skb lists below the sysctl_skb_defer_max >> 1 IPI threshold, or an IPI that races with CPU teardown. Deferred skbs may also remain stranded on idle remote CPUs when the offlined CPU was the last online CPU on its NUMA node.
What should be done if the affected CPU is brought back online?
The description states that skbs left in the offline CPU's skb_defer_nodes lists remain stranded until that CPU is brought back online. The resolved change also resets defer_ipi_scheduled when an asynchronous IPI submission fails because the target CPU went offline, allowing later IPI kicks after the CPU returns online.