Cloudanix VulnDB

CVE-2026-99192

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

Certain network cards in Linux systems can stop sending data correctly when the same packet is reused quickly, leading to slowdowns or interruptions until the interface resets itself.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The bcmgenet driver stores transmission metadata in skb control blocks without first unsharing the buffer, so reuse of a shared skb overwrites prior values and prevents correct completion handling and BQL byte accounting.

Why it matters to the business

Transmit queues on affected network interfaces can stall after periods of high or cloned traffic, causing throughput loss, packet delays, and potential need for manual queue resets until a watchdog timer intervenes.

How an attack unfolds

An attacker or automated test uses packet-generation utilities to feed the driver multiple clones of the same skb; each new transmit overwrites the control block of the still-queued earlier copy, leaving BQL unaware of completed bytes and stalling the queue.

How to fix it

Apply the upstream kernel commit that calls skb_unshare before writing the control block; rebuild and deploy the updated kernel on all systems that use the bcmgenet driver.

How to confirm the fix worked

Reproduce the pktgen clone_skb scenario on a patched kernel and confirm that byte_queue_limits/inflight returns to zero once transmission ceases.

Typical attack path

  1. Locate hosts exposing bcmgenet-based interfaces
  2. Generate cloned skbs with tools such as pktgen in clone_skb mode
  3. Direct sustained traffic at the interface to keep multiple copies in the ring
  4. Observe nonzero inflight byte counts after traffic stops

How to detect it

Inspect kernel logs for transmit queue watchdog resets on bcmgenet devices and periodically read byte_queue_limits/inflight counters after traffic has stopped to detect lingering nonzero values.

What your security team should do

  • Expedite kernel updates containing the skb unshare fix for any bcmgenet hardware
  • Add monitoring for stalled transmit queues and watchdog resets
  • Include clone-skb reproduction tests in pre-deployment validation

The record

In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: unshare the skb before writing the control block bcmgenet stores first_cb, last_cb and bytes_sent in the skb control block and reads them back on completion to free the skb and credit BQL. ether_setup() leaves IFF_TX_SKB_SHARING set, so the stack can resubmit a shared skb that is still in the ring. The next transmit overwrites last_cb, 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 clone_skb mode, which hands the driver the same skb while earlier copies are still in the ring: modprobe pktgen pg=/proc/net/pktgen echo "add_device eth0" > $pg/kpktgend_0 echo "dst_mac AA:BB:CC:DD:EE:FF" > $pg/eth0 echo "dst 192.0.2.1" > $pg/eth0 echo "clone_skb 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/byte_queue_limits/inflight inflight stays nonzero on the now idle queue. clone_skb 0 leaves it at zero.

Affected packages

Ecosystem Package Introduced Fixed