Look up another CVE · open CVE-2026-53232 in the interactive tracker
CVE-2026-53232
net: phy: clean the sfp upstream if phy probing fails
Published 2026-06-25 (4 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-53232 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| 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.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.
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/phy/phy_device.c
- What this is
- ETHERNET PHY LIBRARYMAINTAINERS section matched on drivers/net/phy/ · netdev@vger.kernel.org · Maintained
- Kernel module
- libphy
Check it on the machine
grep -w CONFIG_PHYLIB /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 libphyPrints 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.
- bookworm, trixieMnot built on amd64/cloud-amd64
- forky, sidBnot built on amd64/cloud-amd64
- M
- a module where it is built at all; some flavours do not build it
- B
- built in on some, a module on others, absent on the rest
- Build switch
- CONFIG_PHYLIB
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-06-25 (4 months ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.25%, higher than 15.8% 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 |
|---|---|---|
| 5.5 | 6.6.143 | 12fb84dc4dc8 |
| 5.5 | 6.12.94 | 9326b654f90a |
| 5.5 | 6.18.36 | 3a254779c169 |
| 5.5 | 7.0.13 | 0b27701ce931 |
| 5.5 | 7.1 | 48774e87bbaa |
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:AAttack vector, adjacent network
- The stale upstream pointer is dereferenced from SFP cage events such as module presence and LOS/link changes, which can be driven by a directly connected SFP link partner. It is not reachable through ordinary routed network packets or an unprivileged syscall path.
- AC:LAttack complexity, low
- Once an affected PHY/SFP configuration has hit the failed-probe state, later SFP events reliably call the stale upstream callbacks. There is no attacker-won race or complex timing requirement in the event path.
- PR:NPrivileges required, none
- An adjacent physical/link-layer attacker does not need kernel privileges or authentication to trigger SFP signal events. No CAP_NET_ADMIN or user-namespace route is required for that trigger path.
- UI:NUser interaction, none
- After the system is in the vulnerable failed-probe state, exploitation is triggered by SFP events without a victim user performing an action. The attacker can induce the relevant link/module event directly.
- S:UScope, unchanged
- The affected code and resulting impact are within the Linux kernel networking/PHY security authority. There is no VM, IOMMU, or separate-scope boundary crossing.
- C:HConfidentiality impact, high
- The bug leaves a dangling `phy_device` upstream pointer that later SFP callbacks dereference, creating a kernel use-after-free style condition. Kernel UAF conditions are treated as capable of exposing arbitrary kernel memory.
- I:HIntegrity impact, high
- The stale pointer callbacks read and write fields through the freed or invalid `phy_device` and may reach attacker-influenced object contents after reuse. Kernel UAF memory corruption is treated as potentially enabling arbitrary write or code execution.
- A:HAvailability impact, high
- Even without full exploitation, dereferencing the dangling upstream pointer during SFP events can crash or oops the kernel. Kernel crashes are high availability impact.