CVE-2026-98574: net: bcmgenet: stop Tx NAPI before disabling the queues
In the Linux kernel, the following vulnerability has been resolved:
net: bcmgenet: stop Tx NAPI before disabling the queues
bcmgenetnetifstop() and the Wake-on-LAN branch of bcmgenetsuspend() both disable the Tx queues first and stop Tx NAPI several steps later. A completion in flight calls netiftxwakequeue() in between, and nothing stops the queue again, so a transmit can reach the rings after they have been freed.
Close is safe because devdeactivatemany() stops the qdisc first. bcmgenetsuspend() does not, so stop Tx NAPI before the queues on both paths.
KASAN on a Raspberry Pi CM4, driven from an MTU change because suspend freezes user space before the callback runs:
BUG: KASAN: use-after-free in bcmgenetxmit+0x17f8/0x2258 Write of size 8 at addr ffffff8055844a68 by task ksoftirqd/0/14 bcmgenetxmit+0x17f8/0x2258 devhardstartxmit+0x13c/0x588 schdirectxmit+0x108/0x340 devqueuexmit+0x1190/0x3848
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the bcmgenet suspend paths, stop Tx NAPI before disabling the Tx queues, including the Wake-on-LAN branch of bcmgenet_suspend().
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel bcmgenet network driver are implicated. The reported reproduction occurred on a Raspberry Pi CM4, but the provided information does not limit the issue to that platform.
What conditions trigger the use-after-free?
The race occurs when a transmit completion wakes a Tx queue after the queues have been disabled but before Tx NAPI has been stopped. It affects the bcmgenet network-interface stop path and the Wake-on-LAN branch of suspend; the report reproduced it during an MTU change while suspend froze user space.
Is ordinary device close affected in the same way?
The provided information states that close is safe because dev_deactivate_many() stops the qdisc first. The unsafe path described is suspend, along with the ordering in bcmgenet_netif_stop().
How can administrators identify a possible occurrence?
A manifestation may appear as a KASAN use-after-free report in bcmgenet_xmit, potentially in ksoftirqd, with transmit-path frames such as dev_hard_start_xmit, sch_direct_xmit, and __dev_queue_xmit.