CVE-2022-48812

What it actually does

Use-after-free panic in mdiobus_free when devm_mdiobus_free is invoked from devres_release_all during driver unbind on shutdown if the MDIO bus was never unregistered; triggered by device links between DSA switch and master when the master resides on a bus that unbinds consumers at shutdown.

Why it matters to the business

Unexpected kernel panics or system instability during shutdown or driver unload on affected Linux systems using the lantiq_gswip DSA switch driver, increasing operational risk and potential downtime in network appliances or embedded devices.

How an attack unfolds

An attacker with local access or the ability to trigger device unbind/shutdown sequences (for example via power management or bus-level events) can cause the kernel to release a still-registered MDIO bus through devres, leading to a use-after-free condition and panic; the flaw is not known to be remotely exploitable in isolation.

How to fix it

Update the Linux kernel to the fixed commit e177d2e85ebcd3008c4b2abc293f4118e04eedef or later stable releases containing the patch; replace devm_mdiobus_alloc with non-devres mdiobus_alloc and ensure manual mdiobus_free after unregister.

How to confirm the fix worked

Confirm kernel source contains the referenced commit or verify that devm_mdiobus_alloc calls have been replaced and manual free logic added in drivers/net/dsa/lantiq_gswip.c; test shutdown/unbind sequences on affected hardware.

Typical attack path

1. Identify system using lantiq_gswip DSA driver with device links to DSA master on fsl-mc or similar shutdown-unbinding bus
2. Trigger driver unbind or system shutdown path
3. Cause devres_release_all to invoke devm_mdiobus_free on a still-registered bus
4. Trigger mdiobus_free panic due to use-after-free

How to detect it

Review kernel logs for mdiobus_free panic messages during shutdown or unbind events; examine dmesg or syslog for traces involving lantiq_gswip or devres release paths around the time of system restart.

What your security team should do

• Prioritize kernel upgrade on all systems exposing the lantiq_gswip driver
• Monitor vendor advisories for backported fixes in distribution kernels
• Test shutdown and driver unload paths in lab environments before production rollout
• Review device link and DSA master configurations for similar devres patterns in other DSA drivers