CVE-2021-47234

What it actually does

The flaw fails to call clk_disable_unprepare() on error paths inside mtk_phy_init(), leaving clock resources allocated and causing memory and resource leaks.

Why it matters to the business

Repeated initialization failures on affected hardware can exhaust clocks and memory, leading to degraded device stability or outages in embedded or networking equipment.

How an attack unfolds

An attacker with local access triggers repeated failures in PHY initialization to accumulate leaked clock resources until the system becomes unstable; no remote unauthenticated path is known.

How to fix it

Apply the upstream fix that adds clk_disable_unprepare() in the error path; for tungstenite-rs users the equivalent correction is present in commit 8b3ecd3cc0008145ab4bc8d0657c39d09db8c7e2.

How to confirm the fix worked

Confirm the corrected clk_disable_unprepare() call exists in mtk_phy_init() error handling and that no clock resources remain enabled after an initialization failure.

Typical attack path

1. Obtain local execution context on a device using the affected PHY driver
2. Force mtk_phy_init() to take an error path repeatedly
3. Accumulate leaked clock resources until exhaustion

How to detect it

Review kernel logs for repeated mtk_phy_init error paths without corresponding clk_disable_unprepare messages; inspect for growing clock reference counts via debugfs or kernel memory statistics.

What your security team should do

• Patch affected kernels or upgrade tungstenite-rs to commit 8b3ecd3cc0008145ab4bc8d0657c39d09db8c7e2 immediately
• Monitor for repeated PHY initialization failures in system logs
• Limit local access on devices using the mtk-tphy driver until patched