CVE-2026-53088

What it actually does

This is an off-by-one memory management flaw in the Linux kernel Broadcom GENET Ethernet driver transmit-control-block handling. The driver incorrectly returns the wrong transmit control block when rewinding the transmit ring write pointer, which can cause the wrong descriptor/control structure to be cleaned up. In practical terms, the flaw can corrupt driver/kernel state during network transmit cleanup on systems using the bcmgenet driver, potentially resulting in kernel instability, network device failure, or a denial of service. Because the bug is in kernel-mode driver code, any successful exploitation impact occurs at the operating-system kernel level, but no public exploit maturity or active exploitation is currently indicated.

Why it matters to the business

Organizations running Linux on hardware that uses the Broadcom GENET Ethernet driver may experience unexpected network interface failures, host instability, or crashes if the vulnerable code path is triggered. The operational risk is highest for embedded, appliance, edge, router, IoT, or ARM-based Linux systems where this driver is commonly present and where network availability is business critical. Current threat intelligence indicates low EPSS likelihood, no known CISA KEV listing, no ransomware association, and no public exploit maturity, so this should generally be handled through normal kernel update cycles unless affected systems are internet-facing, safety-critical, or difficult to recover remotely.

How an attack unfolds

An attacker would first need to identify a Linux system using the affected Broadcom GENET Ethernet driver. The vulnerable path is associated with transmit buffer/control-block handling, so exploitation would likely require causing the system to generate network transmit activity through the affected interface, or otherwise reaching code paths that allocate, rewind, and clean up transmit control blocks. By repeatedly stressing transmit operations, an attacker may be able to trigger incorrect cleanup of a transmit control block due to the off-by-one pointer handling error. The most plausible observable outcome is driver malfunction, kernel warnings, interface resets, or a system crash. Reliable code execution is not indicated by the available information and there is no known public exploit at this time.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the bcmgenet_put_txcb off-by-one transmit-control-block handling issue. If vendor-maintained kernels are used, install the relevant distribution, device-vendor, or appliance firmware update rather than attempting to patch the kernel manually. Because no fixed package versions were provided, track the fix through the operating-system or device vendor advisories for the affected kernel branch. Where immediate patching is not feasible, reduce exposure by disabling unused Broadcom GENET interfaces, moving affected devices behind trusted network segments, limiting untrusted traffic paths that can induce high outbound traffic through the interface, and ensuring watchdog or out-of-band recovery is available for remote embedded systems.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package or firmware build includes the bcmgenet_put_txcb fix. On Linux systems, check whether the bcmgenet driver is present or loaded using commands such as `lsmod | grep bcmgenet`, `modinfo bcmgenet`, `dmesg | grep -i bcmgenet`, and by reviewing `/sys/class/net/*/device/driver` links for interfaces bound to the bcmgenet driver. Validate that the system has booted into the updated kernel, not merely installed it. For high-assurance validation, review the vendor kernel changelog or source package for the fix in `drivers/net/ethernet/broadcom/genet/`. After updating, perform controlled network transmit stress testing and monitor kernel logs for absence of bcmgenet-related warnings, oopses, transmit timeouts, or interface resets.

Typical attack path

1. Identify Linux systems or appliances using Broadcom GENET Ethernet hardware and the bcmgenet kernel driver.
2. Confirm the affected kernel build includes the vulnerable bcmgenet transmit-control-block logic.
3. Generate or induce network transmit activity through the affected interface, potentially at high volume or with timing conditions that exercise transmit ring wraparound and cleanup behavior.
4. Trigger the off-by-one transmit control block rewind/cleanup condition.
5. Cause kernel driver state corruption, network interface disruption, kernel warning/oops, or denial of service.

How to detect it

There are no known public exploitation indicators for this issue, and exploitation would likely resemble driver instability rather than a distinctive intrusion pattern. To assess possible prior triggering, review kernel logs, persistent journal logs, crash dumps, netconsole output, appliance health logs, and monitoring alerts for bcmgenet-related failures, transmit queue timeouts, kernel oops/panic events, interface resets, or unexpected reboots. Relevant sources include `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, `journalctl -k`, `dmesg`, kdump/vmcore artifacts, systemd journal persistence, device firmware logs, and network interface monitoring. Correlate events with unusual spikes in outbound traffic, repeated interface resets, or loss-of-connectivity incidents on interfaces bound to the bcmgenet driver. Because the known issue is a memory corruption bug in a kernel driver, absence of a unique payload string means forensic conclusions should be based on crash context, affected driver presence, timing, and traffic correlation rather than a single IOC.

• bcmgenet
• bcmgenet_put_txcb
• NETDEV WATCHDOG
• transmit queue timed out
• tx timeout
• kernel BUG
• kernel NULL pointer dereference
• Oops:
• Kernel panic
• genet
• Broadcom GENET
• drivers/net/ethernet/broadcom/genet
• /sys/class/net/*/device/driver
• /var/crash
• /proc/vmcore

What your security team should do

• Inventory Linux systems, appliances, and embedded devices that use the Broadcom GENET Ethernet driver or Broadcom GENET Ethernet hardware.
• Prioritize updates for remotely managed, internet-exposed, high-availability, edge, router, gateway, and appliance deployments where a crash or network interface failure would cause operational impact.
• Apply vendor kernel or firmware updates that include the bcmgenet transmit-control-block fix; ensure systems are rebooted into the fixed kernel.
• If patching is delayed, disable unused affected interfaces and restrict untrusted traffic paths capable of driving sustained transmit activity through the affected interface.
• Monitor kernel logs and device health telemetry for bcmgenet errors, transmit timeouts, kernel oops messages, interface resets, and unexpected reboots.
• Do not treat this as currently exploited at scale based on available intelligence: EPSS is low, it is not in CISA KEV, it is not associated with ransomware, and exploit maturity is listed as none.