CVE-2026-53086

What it actually does

This is a race condition in the Linux kernel Broadcom GENET Ethernet driver timeout handling path. When one transmit queue times out, the affected handler attempts to take down all transmit queues instead of only restarting the timed-out queue. Queues that are still operating can race with the global teardown/restart logic, potentially causing network instability, packet transmission failures, interface resets, kernel warnings, hangs, or denial of service on systems using the bcmgenet driver. The issue is most relevant to Linux systems with Broadcom GENET network hardware, commonly found in some embedded, appliance, and ARM-based platforms. There is no indication from the provided data that this enables remote code execution or privilege escalation.

Why it matters to the business

The primary business risk is loss of network reliability on affected Linux-based devices. Systems using the vulnerable driver may experience intermittent connectivity loss, degraded packet transmission, service disruption, or device instability if the race is triggered. This can affect appliances, embedded systems, gateways, or other Linux devices that depend on Broadcom GENET Ethernet connectivity. The current exploitation signal is low: EPSS is 0.00304, exploit maturity is listed as none, and it is not in the CISA Known Exploited Vulnerabilities catalog or associated with known ransomware use. Because the issue was published 48 days ago, organizations with affected kernel builds should still plan remediation through normal kernel update cycles, prioritizing internet-facing or operationally critical network devices that use this driver.

How an attack unfolds

An attacker would need to create conditions that cause a transmit queue timeout on a Linux system using the Broadcom GENET Ethernet driver. This could potentially be attempted by driving unusual or sustained network traffic patterns, inducing congestion, or otherwise stressing the network interface until the driver's timeout handler is invoked. Once invoked, the vulnerable logic attempts to stop or restart all transmit queues rather than isolating the failed queue. Because other queues may still be active, this creates race conditions between normal transmission activity and the timeout recovery path. The likely attacker outcome is disruption: unstable Ethernet behavior, interface resets, packet loss, kernel warnings, or denial of service. There is no evidence in the supplied intelligence of public exploit code, active exploitation, ransomware use, or named threat actor exploitation.

How to fix it

Apply a Linux kernel update that includes the bcmgenet timeout handler fix, where the driver restarts only the timed-out transmit queue instead of taking down all queues. If vendor-specific kernels are used, obtain patched packages from the device, distribution, appliance, or SoC vendor. If no fixed version is listed by the distribution, track the vendor advisory or upstream stable kernel backport that contains the fix for the bcmgenet driver. Mitigations include reducing exposure of affected devices to untrusted or high-volume network traffic, isolating management networks, rate-limiting hostile traffic where feasible, and monitoring for interface instability. If the device does not use the bcmgenet driver or Broadcom GENET Ethernet hardware, it is unlikely to be affected by this specific flaw.

How to confirm the fix worked

Confirm exposure by checking whether the system runs a Linux kernel build that includes the bcmgenet driver and whether Broadcom GENET Ethernet hardware is present. Validate remediation by confirming the installed kernel package or vendor firmware includes the upstream fix for the bcmgenet timeout handling path. Reboot into the patched kernel where required. After patching, review kernel logs during sustained network activity and confirm there are no recurring bcmgenet transmit timeout messages, NETDEV WATCHDOG events, queue restart loops, interface resets, or kernel warnings associated with the driver. For source-based validation, confirm the driver behavior restarts only the timed-out transmit queue rather than taking down all transmit queues.

Typical attack path

1. Identify a Linux-based target likely to use Broadcom GENET Ethernet hardware and the bcmgenet kernel driver.
2. Generate network conditions that increase the likelihood of transmit queue timeouts, such as high traffic volume, congestion, malformed traffic patterns, or repeated interface stress.
3. Trigger the vulnerable timeout handler for one transmit queue.
4. The handler incorrectly attempts to take down all transmit queues, including queues that may still be active.
5. Race conditions occur between queue teardown/restart logic and ongoing packet transmission.
6. The target experiences network instability, packet loss, interface resets, kernel warnings, hangs, or denial of service.

How to detect it

Retrospective detection should focus on signs of attempted or successful denial of service rather than malware artifacts. Review kernel logs, system journals, appliance diagnostics, network interface logs, and monitoring data for recurring Broadcom GENET driver errors, transmit queue timeouts, NETDEV WATCHDOG messages, interface resets, link flapping, sudden packet loss, or kernel warnings and panics around network stress events. Useful sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, dmesg output, device health telemetry, switch port error counters, interface statistics, and network monitoring alerts. Correlate driver timeout events with unusual inbound or outbound traffic spikes, sustained high packet rates, congestion, or repeated connectivity loss. There are no known attacker-specific payloads, files, registry keys, malware names, or network signatures associated with exploitation from the supplied data.

• bcmgenet
• NETDEV WATCHDOG
• transmit queue timed out
• tx timeout
• queue timed out
• bcmgenet_timeout
• genet
• kernel: bcmgenet
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• journalctl -k
• dmesg

What your security team should do

• Inventory Linux systems, appliances, and embedded devices that use Broadcom GENET Ethernet hardware or load the bcmgenet driver.
• Prioritize patching for network-critical, internet-adjacent, branch, industrial, or appliance-like systems where connectivity loss would have operational impact.
• Apply vendor kernel or firmware updates containing the bcmgenet timeout handler fix; use distribution-supported packages where available.
• If immediate patching is not possible, reduce untrusted traffic exposure to affected interfaces and apply network rate limits or segmentation where operationally feasible.
• Monitor kernel, system, and network device logs for transmit timeout events, bcmgenet errors, NETDEV WATCHDOG messages, interface resets, and repeated link flaps.
• Because exploit maturity is currently none, EPSS is low, and the issue is not KEV-listed, handle as a reliability and availability patch unless local telemetry indicates active targeting or repeated unexplained interface failures.