UBUNTU-CVE-2026-99192: Medium severity ubuntu/linux-azure vulnerability
In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: unshare the skb before writing the control block bcmgenet stores firstcb, lastcb and bytessent in the skb control block and reads them back on completion to free the skb and credit BQL. ethersetup() leaves IFFTXSKBSHARING set, so the stack can resubmit a shared skb that is still in the ring. The next transmit overwrites lastcb, so the earlier slots complete without crediting their bytes and BQL stalls the queue until the watchdog resets it. Unshare the skb before writing the control block. Reproduce with pktgen in cloneskb mode, which hands the driver the same skb while earlier copies are still in the ring: modprobe pktgen pg=/proc/net/pktgen echo "adddevice eth0" > $pg/kpktgend0 echo "dstmac AA:BB:CC:DD:EE:FF" > $pg/eth0 echo "dst 192.0.2.1" > $pg/eth0 echo "cloneskb 8" > $pg/eth0 echo "count 0" > $pg/eth0 echo start > $pg/pgctrl & sleep 5 echo stop > $pg/pgctrl wait cat /sys/class/net/eth0/queues/tx-0/bytequeuelimits/inflight inflight stays nonzero on the now idle queue. cloneskb 0 leaves it at zero.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In bcmgenet, unshare the skb before writing first_cb, last_cb, and bytes_sent to the skb control block.
Event History
Frequently Asked Questions
What systems are realistically exposed to this issue?
Systems using the Linux bcmgenet network driver are affected when they transmit shared socket buffers that remain in the transmit ring. The listed Ubuntu kernel packages include linux, linux-aws-fips, linux-azure, linux-azure-fips, linux-fips, linux-gcp, linux-gcp-fips, and linux-oracle.
What traffic pattern is needed to trigger the problem?
The driver must receive the same shared skb again while earlier copies are still pending in the transmit ring. The provided reproduction uses pktgen with clone_skb set to 8; using clone_skb 0 does not leave the queue inflight count nonzero.
What is the operational impact if the issue is triggered?
Transmit completions can fail to credit the correct byte counts to BQL, causing the transmit queue to stall. The queue remains stalled until the watchdog resets it.
How can I check whether a transmit queue is stuck in the affected state?
After stopping traffic and confirming the queue is otherwise idle, inspect /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight. In the described affected condition, inflight remains nonzero on an idle queue.