CVE-2026-53087

What it actually does

This is a Linux kernel denial-of-service flaw in the Broadcom GENET Ethernet driver. During transmit-queue reclaim, the driver fast-forwards the write pointer to discard frames that are still considered in flight, but fails to return the associated buffer descriptors to the free descriptor pool. Over time, repeated queue reset/reclaim activity can leak transmit buffer descriptors, exhausting the device’s transmit resources and preventing normal network transmission. The fix ensures dropped frames are accounted for and their descriptors are returned to the free pool, while also notifying the network device stack that data was dropped.

Why it matters to the business

Affected systems that use the Broadcom GENET network driver may experience degraded or lost network connectivity if transmit descriptors are exhausted. For appliances, embedded Linux devices, routers, set-top boxes, IoT gateways, or servers using this driver, the operational impact can include service interruption, remote management loss, monitoring gaps, and the need for manual recovery or reboot. Public exploitation is not currently known, the EPSS score is low, and it is not listed in CISA KEV, so this should generally be prioritized through normal kernel maintenance unless the affected driver is used in critical or remotely managed infrastructure.

How an attack unfolds

An attacker would need to cause conditions that repeatedly trigger transmit-queue reclaim or reset behavior on a system using the affected Broadcom GENET driver. By driving traffic or fault conditions that leave frames in flight when the driver reclaims the transmit queue, the attacker may cause the driver to drop outstanding frames without returning their buffer descriptors to the free pool. As this repeats, the pool of available transmit descriptors shrinks until the interface can no longer reliably send packets. The practical result is denial of service at the network interface level rather than code execution or privilege escalation. Exploitability depends heavily on hardware presence, driver configuration, network reachability, and the ability to trigger the relevant queue-reclaim path.

How to fix it

Update the Linux kernel to a version that includes the bcmgenet transmit descriptor leak fix. If using a vendor distribution, apply the vendor-provided kernel security or stability update rather than relying only on upstream version numbers. For embedded or appliance firmware, obtain updated firmware from the device vendor that incorporates the corrected bcmgenet driver. If immediate patching is not possible, reduce exposure by limiting untrusted network traffic to affected interfaces, placing devices behind filtering controls, using alternate network interfaces where available, and preparing operational recovery procedures such as controlled interface reset or reboot. Because no affected product list or exact fixed package versions were provided, confirm remediation status against the relevant distribution, kernel tree, or hardware vendor advisory.

How to confirm the fix worked

Confirm whether the system uses the Broadcom GENET driver by checking loaded modules, kernel configuration, hardware inventory, and network driver bindings, for example with commands such as `ethtool -i <interface>`, `lsmod`, `modinfo bcmgenet`, and `/sys/class/net/<interface>/device/driver`. Validate the fix by confirming the running kernel or vendor firmware includes the upstream bcmgenet patch that returns leaked free buffer descriptors during transmit queue reclaim. After updating, perform a reboot if required so the fixed kernel is active. Monitor the affected interface under normal and stress traffic for stable transmit behavior, absence of repeated TX queue timeouts, and no progressive loss of descriptor availability or network throughput. Confirm package state using distribution package tools and compare against the vendor advisory for the corrected kernel build.

Typical attack path

1. Identify a Linux system using the Broadcom GENET Ethernet driver.
2. Establish network-level reachability to the affected interface or otherwise influence traffic patterns through it.
3. Generate traffic or conditions that contribute to transmit-queue reclaim/reset behavior with frames still in flight.
4. Repeat the condition so transmit buffer descriptors are leaked rather than returned to the free pool.
5. Cause transmit descriptor exhaustion, leading to packet transmission failures, interface degradation, or loss of network connectivity.

How to detect it

Look for evidence of network-interface denial of service rather than host compromise. Useful sources include kernel logs, system journal logs, network device telemetry, interface counters, uptime/reboot history, NMS alerts, and packet-drop monitoring. Search for repeated transmit queue timeouts, Broadcom GENET driver messages, interface resets, carrier changes, rising transmit drops or errors, and periods where the host stopped responding on the affected interface while remaining otherwise operational. In Linux environments, review `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, interface statistics from `ip -s link`, `ethtool -S`, and monitoring data for progressive TX failures. Because this flaw is a resource leak in a network driver and no public exploit artifacts are known, there are no reliable attacker-specific payload indicators; detection should focus on anomalous repeated TX failures or descriptor/resource exhaustion patterns on systems using `bcmgenet`. Correlate events with spikes in traffic, link flaps, watchdog resets, or external scans, but treat these as circumstantial unless supported by a reproducible trigger pattern.

• bcmgenet
• genet
• TX timeout
• transmit queue timed out
• NETDEV WATCHDOG
• tx queue
• carrier lost
• carrier acquired
• link down
• link up
• /sys/class/net/
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• ethtool -S

What your security team should do

• Inventory Linux systems, embedded devices, and appliances that use Broadcom GENET Ethernet hardware or the `bcmgenet` driver.
• Prioritize patching for devices where loss of the affected network interface would disrupt production services, remote administration, safety monitoring, or network edge connectivity.
• Apply vendor kernel or firmware updates that include the bcmgenet descriptor leak fix during the next appropriate maintenance window.
• For devices that cannot be patched quickly, restrict untrusted traffic paths to affected interfaces and ensure out-of-band or alternate management access is available.
• Add monitoring for network interface transmit errors, TX queue timeouts, link resets, sudden packet drops, or devices becoming unreachable.
• Document recovery procedures for affected systems, including safe interface restart, service restart, or reboot steps.
• Track vendor advisories because exact fixed versions vary by Linux distribution, kernel branch, and embedded firmware vendor.