CVE-2022-48754

What it actually does

The vulnerability is a use-after-free in phy_detach() where phy_device_reset() is invoked after put_device(), allowing the phydev structure to be freed before the reset call completes.

Why it matters to the business

Systems running affected Linux kernels may experience kernel crashes, memory corruption, or potential local code execution, disrupting services and requiring urgent patching across fleets of servers, embedded devices, and Android-based products.

How an attack unfolds

An attacker with local access triggers PHY device detachment (via network interface operations or driver unload) while racing the put_device() call, causing the subsequent phy_device_reset() to operate on freed memory and achieve arbitrary kernel read/write or control-flow hijacking.

How to fix it

Update the Linux kernel to a version containing commit 67d271760b037ce0806d687ee6057edc8afd4205 or later; rebuild and reboot all affected systems. Where immediate patching is not possible, restrict untrusted local access and avoid unnecessary PHY device attach/detach operations.

How to confirm the fix worked

Confirm the running kernel contains the fix commit or is newer than the vulnerable versions listed for the stable tree; inspect phy_detach() source to verify phy_device_reset() precedes put_device(); test detachment paths under load to ensure no crash occurs.

Typical attack path

1. Obtain local code execution or shell access on target system
2. Trigger network interface or PHY-related detach operations that invoke phy_detach()
3. Race or manipulate timing so put_device() frees the phydev before phy_device_reset() runs
4. Leverage resulting use-after-free for kernel memory corruption and privilege escalation

How to detect it

Review kernel logs for oops, panic, or slab-use-after-free warnings mentioning phy_detach or phylib; correlate with processes performing frequent network interface attach/detach; examine audit logs for unusual local activity around PHY driver unload times.

What your security team should do

• Prioritize kernel upgrades on all internet-facing and multi-tenant systems within the next maintenance window
• Apply compensating controls such as seccomp, LSMs, and reduced local privileges until patches are deployed
• Monitor for kernel oops or panic reports related to phylib and PHY device handling
• Inventory downstream embedded and Android devices that incorporate the affected kernel tree