CVE-2026-93145: clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister()
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: gdsc: tear down per-domain genpds in gdscunregister()
gdscunregister() removes the OF provider entry and tears down the parent/subdomain wiring, but never calls pmgenpdremove() on the individual genericpmdomain structures registered by gdscinit():
void gdscunregister(struct gdscdesc desc) { struct device dev = desc->dev; sizet num = desc->num;
gdscpmsubdomainremove(desc, num); ofgenpddelprovider(dev->ofnode); }
That leaves dangling entries on the global gpdlist. After a provider unbind/rebind cycle (deferred-probe replay during early boot, real module unload of a clk driver that owns GDSCs, or an OF-overlay tear- down) the next gdscinit() will end up trying to re-register a name that is still in the list and pmgenpdinit() returns -EEXIST.
While we are here, flip the order so the consumer-facing OF provider entry is the first thing removed -- otherwise a fresh ofgenpdgetfromprovider() call racing with the teardown could attach to a domain that is mid-removal.
Iterate the scs[] array and pmgenpdremove() each registered domain after the subdomain links are torn down. The regulators stay devm- managed (devmregulatorgetoptional() in gdscregister()), so the release happens automatically when the underlying device is unbound; just the genpd accounting needs to be undone explicitly.
Affected Software
Event History
Frequently Asked Questions
Which systems are most likely to encounter this issue?
Systems using Qualcomm GDSC power-domain providers are exposed when a provider is unbound and later rebound. Examples described include deferred-probe replay during early boot, unloading a clock driver that owns GDSCs, and device-tree overlay teardown.
What symptom indicates that a previous provider teardown was incomplete?
After a provider unbind/rebind cycle, a subsequent gdsc_init() can fail because pm_genpd_init() returns -EEXIST. This occurs when generic power-domain entries from the previous instance remain on the global gpd_list.
Is there a teardown race affecting new power-domain consumers?
Yes. If the OF provider entry remains available while teardown is underway, a new of_genpd_get_from_provider() call could attach to a domain that is mid-removal. The resolved behavior removes the consumer-facing OF provider entry before removing subdomain links and individual generic power domains.