In the Linux kernel, the following vulnerability has been resolved:
phy: mdio: fix memory leak
Syzbot reported memory leak in MDIO bus interface, the problem was in
wrong state logic.
MDIOBUS_ALLOCATED indicates 2 states:
1. Bus is only allocated
2. Bus allocated and __mdiobus_register() fails, but
device_register() was called
In case of device_register() has been called we should call put_device()
to correctly free the memory allocated for this device, but mdiobus_free()
calls just kfree(dev) in case of MDIOBUS_ALLOCATED state
To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED
_before_ calling device_register(), because put_device() should be
called even in case of device_register() failure.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel memory leak in the MDIO bus interface, used around network PHY device handling. The public record describes incorrect cleanup logic after device registration failure. No source in the bundle reports active exploitation or a CVSS score.
Executive priority
Treat as routine kernel hygiene unless affected custom or embedded network devices are business-critical. The absence of CVSS and exploitation evidence lowers urgency, but kernel backport tracking is still required.
Technical view
The flaw is in MDIO bus state handling. When __mdiobus_register() fails after device_register() was called, mdiobus_free() could kfree() the structure instead of using put_device(), leaving device-managed memory unreleased. Stable kernel commits adjust state handling before device_register().
Likely exposure
Exposure is most plausible on Linux systems using affected kernel versions and MDIO/PHY networking paths, especially embedded, appliance, and network-device builds. The bundle does not identify a remote attack surface or affected distributions.
Exploitation context
The issue was reported by syzbot as a memory leak. KEV is false, and the provided sources do not claim exploitation in the wild, public exploit availability, privilege impact, or reliable denial-of-service conditions.
Researcher notes
Evidence is limited to the CVE description and Linux stable commit references. The source bundle supports a memory-leak classification but does not provide exploitability details, affected distro package names, or operational workarounds.
Mitigation direction
Update to a Linux kernel or vendor package containing the stable MDIO fix.
Prioritize embedded and network-facing systems with custom kernels or PHY drivers.
If using a vendor kernel, verify whether the fix was backported.
If no patch is available, monitor vendor guidance for supported mitigations.
Validation and detection
Inventory Linux kernel versions across servers, appliances, and embedded images.
Check vendor changelogs or kernel source for the referenced MDIO fix commits.
Identify systems using MDIO/PHY network drivers or custom kernel builds.
Review memory-leak telemetry for affected test or staging kernels.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2021-47416 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.