CVE-2021-47416

What it actually does

Memory leak occurs in MDIO bus interface when MDIOBUS_ALLOCATED state is mishandled: device_register() is invoked after allocation but mdiobus_free() only performs kfree instead of put_device(), leaving device memory allocated.

Why it matters to the business

Gradual exhaustion of kernel memory on Linux systems handling MDIO devices such as network hardware can lead to degraded performance or denial of service; the long-published flaw carries low exploitation probability and no ransomware linkage.

How an attack unfolds

An attacker with local or driver-level access triggers the failure path during __mdiobus_register() after device_register() succeeds, repeatedly causing the leak; listed threat actors reference generic Linux kernel memory issues rather than confirmed campaigns against this specific flaw.

How to fix it

Apply the upstream fix that sets bus->state to MDIOBUS_UNREGISTERED before device_register() and ensure put_device() is called on registration failure; upgrade to a kernel containing the resolution for CVE-2021-47416.

How to confirm the fix worked

Confirm the patch is present by inspecting phy/mdio_bus.c for the state assignment prior to device_register(); test MDIO registration failure paths under memory pressure and verify no leaks via kmemleak or similar tooling.

Typical attack path

1. Obtain ability to load or interact with MDIO bus drivers on target Linux kernel
2. Force __mdiobus_register() to fail after device_register() has executed
3. Invoke mdiobus_free() while state remains MDIOBUS_ALLOCATED
4. Repeat to accumulate leaked device structures until memory pressure occurs

How to detect it

Search kernel logs for repeated MDIO bus allocation and registration failure messages; inspect kmemleak reports or slabinfo for growing numbers of device structures tied to MDIO; correlate with process activity that exercises MDIO registration paths.

What your security team should do

• Prioritize kernel updates on systems exposing MDIO interfaces such as embedded networking devices
• Monitor EPSS and KEV status for any future increase in exploit activity
• Review custom MDIO drivers for similar state-handling errors