CVE-2023-52510

What it actually does

Double call to clk_unregister on the same priv->clk object during error handling in ca8210_probe when of_clk_add_provider fails, causing a use-after-free.

Why it matters to the business

Kernel instability or potential code execution on systems using the ca8210 IEEE 802.15.4 driver, increasing risk for embedded or IoT Linux deployments until patched.

How an attack unfolds

An attacker with the ability to trigger ca8210_probe (such as during device initialization or module load) forces of_clk_add_provider to fail, leading to the first unregister; subsequent ca8210_remove then performs the second unregister on the already-freed object.

How to fix it

Update the Linux kernel to commit 28b68cba378e3e50a4082b65f262bc4f2c7c2add or later stable releases that remove the erroneous clk_unregister and use IS_ERR_OR_NULL checks.

How to confirm the fix worked

Confirm presence of commit 28b68cba378e3e50a4082b65f262bc4f2c7c2add in the kernel tree; exercise the of_clk_add_provider failure path in ca8210_register_ext_clock and verify no double unregister occurs.

Typical attack path

1. Load or attach ca8210 driver causing probe to run
2. Force failure of of_clk_add_provider inside ca8210_register_ext_clock
3. First clk_unregister executes on priv->clk
4. Probe fails and calls ca8210_remove
5. Second clk_unregister operates on freed object resulting in UAF

How to detect it

Review kernel logs for ca8210_probe and clk_unregister errors around device initialization; inspect for crashes or warnings referencing use-after-free in the ieee802154/ca8210 code path.

What your security team should do

• Apply the referenced upstream commit immediately on affected kernel trees
• Audit custom kernels and downstream distributions for the vulnerable ca8210 error handling
• Prioritize patching in environments where the ca8210 driver may be loaded