Look up another CVE · open CVE-2026-64125 in the interactive tracker
CVE-2026-64125
net: bcmgenet: keep RBUF EEE/PM disabled
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-64125 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.176-1 | Update the kernel and reboot. Fixed in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Setting RBUF_EEE_EN | RBUF_PM_EN in RBUF_ENERGY_CTRL breaks the RX path on GENET hardware once MAC EEE becomes active. RX traffic stops flowing while the link stays up and the usual descriptor/RX error counters remain quiet. In that state the MAC still accepts frames (rbuf_ovflow_cnt keeps climbing) but RBUF no longer forwards them to DMA, so rx_packets is no longer incremented at the netdev level. On some boards the corruption ends up as a paging fault in skb_release_data via bcmgenet_rx_poll on an LPI exit. Reproduced on Pi 4B (BCM2711 + BCM54213PE) and confirmed by Florian Fainelli on an internal Broadcom 4908-family board with the same crash signature. RBUF_PM_EN is not publicly documented. This shows up more often now that phy_support_eee() enables EEE by default, but it also affects older kernels as soon as TX LPI is turned on via ethtool, so it is not specific to recent changes. Always clear RBUF_EEE_EN | RBUF_PM_EN in bcmgenet_eee_enable_set so the bits stay off across resets. UMAC and TBUF setup is left alone so TX-side EEE keeps working.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/ethernet/broadcom/genet/bcmgenet.c
- What this is
- BROADCOM GENET ETHERNET DRIVERMAINTAINERS section matched on drivers/net/ethernet/broadcom/genet/ · netdev@vger.kernel.org · Maintained
- Kernel module
- genet
Check it on the machine
grep -wE 'CONFIG_BCMGENET|CONFIG_ETHERNET|CONFIG_NET_VENDOR_BROADCOM' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w genetPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, i386/686, i386/686-pae, i386/rt/686-pae, ppc64el/powerpc64le
- trixieMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_BCMGENET, CONFIG_ETHERNET, CONFIG_NET_VENDOR_BROADCOM
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.55%, higher than 44.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 3.19 | 5.10.258 | 2040eb83f6ad |
| 3.19 | 5.15.209 | f2782ddac82c |
| 3.19 | 6.1.175 | b579f3a73da7 |
| 3.19 | 6.6.142 | 289499907399 |
| 3.19 | 6.12.92 | a212fc08f5c4 |
| 3.19 | 6.18.34 | 3d4ef05266ab |
| 3.19 | 7.0.11 | 49bdf6bbb21b |
| 3.19 | 7.1 | 9a1730245e41 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- The fault is reached in `bcmgenet_rx_poll` during NAPI processing of received Ethernet frames; any remote host that can send traffic to a GENET-equipped, network-connected target (e.g., internet-exposed Raspberry Pi, Broadcom gateway, or edge IoT device) can drive RX activity and LPI exit transitions that trigger the corrupted RX path.
- AC:LAttack complexity, low
- On affected GENET hardware with an EEE-capable link partner (now common and enabled by default via `phy_support_eee()`), the bug reproduces within minutes under normal RX load without attacker-influenced memory layout, and the attacker controls timing by sending sustained or bursty traffic to force LPI entry/exit cycles.
- PR:NPrivileges required, none
- Exploitation does not require authentication or elevated privileges; EEE is enabled automatically at link-up through `bcmgenet_mii_setup()` → `bcmgenet_eee_enable_set()`, so a remote attacker only needs the ability to send network packets to the target interface.
- UI:NUser interaction, none
- No victim action is required beyond the device having a normal link with EEE-capable equipment; the misconfigured RBUF registers and subsequent RX stall or kernel oops occur during routine background network activity.
- S:UScope, unchanged
- Impact is confined to kernel/network availability on the same host (RX path stall, skb corruption, and kernel panic); there is no demonstrated crossing of a VM, container, or IOMMU security boundary.
- C:HConfidentiality impact, high
- Hardware RX desynchronization from incorrectly enabled `RBUF_EEE_EN|RBUF_PM_EN` corrupts skb/DMA ring state and manifests as invalid pointers in `skb_release_data` during `bcmgenet_rx_poll`, consistent with use-after-free/double-free class corruption that can enable arbitrary kernel memory disclosure.
- I:HIntegrity impact, high
- The same skb pointer corruption in the RX teardown path can yield heap write primitives (double-free/incorrect free of sk_buff metadata) during LPI exit, which is the class of memory corruption typically leveraged for kernel control-flow hijacking.
- A:HAvailability impact, high
- The bug reliably causes complete RX failure (silent loss of connectivity while the link remains up) and can escalate to a fatal kernel oops/panic in softirq context, constituting total loss of network availability and potential full system availability loss.