CVE-2026-64125

What it actually does

The flaw is in the Linux kernel Broadcom GENET Ethernet driver. When Energy Efficient Ethernet is enabled, the driver can leave undocumented/unsafe receive-buffer power-management bits enabled. On affected GENET hardware, once low-power idle behavior is triggered, the network link can remain up while received frames stop being forwarded from the receive buffer to DMA. This can cause silent receive-path failure, rising receive-buffer overflow counters, stalled packet reception, and on some systems a kernel paging fault in the receive polling path. The practical impact is primarily denial of service through loss of network connectivity or kernel crash on systems using the bcmgenet driver with EEE active.

Why it matters to the business

Systems that rely on affected Broadcom GENET Ethernet interfaces can lose network connectivity or crash even though the physical link still appears healthy, causing outages that may be difficult for operations teams to diagnose. This is most relevant for embedded Linux systems, appliances, Raspberry Pi 4-class hardware, Broadcom 4908-family platforms, routers, gateways, and other devices using the bcmgenet driver. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has low current EPSS, but the high CVSS score and possibility of remote-triggered service disruption make timely kernel/vendor firmware updates important for exposed or availability-sensitive systems.

How an attack unfolds

An attacker first needs a reachable system using the Linux bcmgenet Ethernet driver on affected Broadcom GENET hardware, with Energy Efficient Ethernet enabled either by default or through administrative configuration such as ethtool. The attacker then sends or times network traffic so the interface transitions through EEE low-power-idle behavior and exits back to active receive processing. On vulnerable systems, the receive buffer may accept frames but fail to pass them to DMA. From the outside, the link may still look up, but the host stops receiving packets or becomes unstable. On some boards, the corrupted receive path can lead to a kernel paging fault in skb_release_data through bcmgenet_rx_poll, causing a crash or reboot. No public exploit maturity is reported, and exploitation is more likely to resemble induced network instability or denial of service than code execution.

How to fix it

Apply a Linux kernel or vendor firmware update that includes the bcmgenet fix to keep RBUF_EEE_EN and RBUF_PM_EN disabled in bcmgenet_eee_enable_set across resets. If no fixed package version is published for a distribution or appliance, obtain a vendor advisory or backport the upstream kernel patch titled "net: bcmgenet: keep RBUF EEE/PM disabled." As a temporary mitigation, disable Energy Efficient Ethernet on affected interfaces where operationally acceptable, for example through ethtool-based network startup configuration, and ensure the setting persists across reboot, link reset, and interface restart. For high-availability systems, consider failover to a non-affected network interface until patched.

How to confirm the fix worked

Confirm whether systems use the bcmgenet driver by checking interface driver information, kernel configuration, device tree/platform data, or boot logs for Broadcom GENET/bcmgenet. Confirm whether Energy Efficient Ethernet is enabled with interface tooling such as ethtool. Validate remediation by verifying the running kernel/vendor image contains the bcmgenet patch that clears RBUF_EEE_EN and RBUF_PM_EN in bcmgenet_eee_enable_set, then exercise link reset, interface restart, and EEE transitions while confirming received packets continue to increment normally and receive-buffer overflow counters do not climb unexpectedly. Also verify there are no new kernel messages containing bcmgenet_rx_poll, skb_release_data, paging faults, or receive-path stalls during traffic testing.

Typical attack path

1. Identify a Linux-based target that uses Broadcom GENET Ethernet hardware and the bcmgenet kernel driver.
2. Confirm or assume Energy Efficient Ethernet is enabled, either by default PHY behavior or administrative configuration.
3. Send network traffic to the affected interface while the link enters and exits low-power idle behavior.
4. Trigger the vulnerable receive-buffer state where frames are accepted by the MAC/RBUF but are no longer forwarded to DMA.
5. Cause packet reception to stall, receive-buffer overflow counters to rise, or the kernel to fault in the bcmgenet receive polling path.
6. Sustain the condition to create a network outage, service unavailability, or device crash/reboot.

How to detect it

To determine whether this was already triggered or exploited, review kernel logs, persistent journal data, crash dumps, netconsole output, and device monitoring around periods of network loss or reboot. Look for kernel oops or panic traces referencing bcmgenet_rx_poll, skb_release_data, or paging faults during receive processing. Correlate those events with interface telemetry showing the link remained up while inbound packet counters stopped increasing. Check driver or hardware counters for receive-buffer overflows, especially rbuf_ovflow_cnt, rising without corresponding normal RX errors. Review configuration history for EEE enablement via ethtool, network scripts, systemd-networkd, NetworkManager, or appliance management settings. Network evidence may show repeated connection failures, ARP/ND resolution failures, or service timeouts without a link-down event. There are no known attacker-specific payload signatures or named threat actors for this CVE, so detection should focus on host artifacts and anomalous network-interface behavior rather than a unique exploit string.

• bcmgenet_rx_poll
• skb_release_data
• Unable to handle kernel paging request
• BUG: unable to handle page fault
• Kernel panic - not syncing
• Oops:
• bcmgenet
• rbuf_ovflow_cnt
• RBUF_EEE_EN
• RBUF_PM_EN
• RBUF_ENERGY_CTRL
• net: bcmgenet
• Energy Efficient Ethernet
• EEE enabled
• ethtool --set-eee
• rx_packets
• RX traffic stops
• MAC still accepts frames
• RBUF no longer forwards

What your security team should do

• Inventory Linux and embedded devices using Broadcom GENET Ethernet hardware or the bcmgenet driver, prioritizing routers, gateways, appliances, Raspberry Pi 4-class systems, and externally reachable devices.
• Patch affected systems with the vendor or kernel update that contains the bcmgenet RBUF EEE/PM fix as soon as available.
• Where patching is delayed, disable Energy Efficient Ethernet on bcmgenet interfaces and make the configuration persistent across reboots and link resets.
• Monitor kernel logs and network telemetry for receive stalls, bcmgenet receive-path crashes, and increasing receive-buffer overflow counters while the link remains up.
• Add availability monitoring that detects the mismatch between link-up status and failed packet reception, because this issue may not raise normal descriptor or RX error counters.
• Treat unexplained crashes with stack traces involving bcmgenet_rx_poll or skb_release_data as possible exploitation or triggering of this vulnerability, especially if preceded by network traffic changes.
• Because this issue is not currently KEV-listed and has low EPSS, prioritize based on exposure and service criticality rather than broad emergency response.