CVE-2026-93263: clk: eswin: Zero-initialize stack-allocated clk_init_data
In the Linux kernel, the following vulnerability has been resolved:
clk: eswin: Zero-initialize stack-allocated clkinitdata
eswinclkregisterpll() and eswinregisterclkdiv() declare a struct clkinitdata on the stack and only initialize some of its fields (parentdata respectively parenthws). clkcorepopulateparentmap() checks parentnames first and parentdata second before falling back to parenthws, so leftover stack garbage in the uninitialized fields hijacks parent resolution and the clk core dereferences a bogus pointer:
Unable to handle kernel NULL pointer dereference at virtual address 000000000000000c Oops [#1] epc : clkregister+0x31a/0x7f0 [<ffffffff805dc774>] clkregister+0x31a/0x7f0 [<ffffffff805dcd76>] devmclkhwregister+0x2a/0x94 [<ffffffff805e319a>] eswinregisterclkdiv+0x80/0xd0 [<ffffffff805e34a0>] eswinclkregisterclks+0x162/0x1a0 [<ffffffff805e3736>] eic7700clkprobe+0x146/0x180 [<ffffffff8065d23c>] platformprobe+0x3c/0x7a
Observed on EIC7700 hardware (with the driver backported to a 6.17 tree); whether the bug triggers depends entirely on what the stack happens to contain when the registration helpers run.
Zero-initialize both structures.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Zero-initialize the stack-allocated struct clk_init_data structures in eswin_clk_register_pll() and eswin_register_clkdiv(), ensuring the parent_names, parent_data, and parent_hws fields do not contain uninitialized stack data.
Event History
Frequently Asked Questions
Which deployments are known to be exposed?
The issue was observed on EIC7700 hardware when the eswin clock driver was backported to a 6.17 kernel tree. The provided information does not establish whether other hardware or configurations are affected.
Is the failure deterministic?
No. Triggering depends entirely on residual contents of the stack when the clock-registration helper functions execute, so the bad parent resolution may not occur consistently.
What operational symptom may indicate this issue?
A kernel NULL-pointer-dereference Oops during clock registration is the reported symptom. The supplied trace includes __clk_register, devm_clk_hw_register, eswin_register_clkdiv, eswin_clk_register_clks, and eic7700_clk_probe.
What is the available remediation?
The fix zero-initializes the stack-allocated clk_init_data structures in eswin_clk_register_pll() and eswin_register_clkdiv(). This prevents uninitialized parent_names or parent_data fields from affecting parent-clock resolution.