https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 07 Oct 2026 15:57:47 +0000 https://cve.radiocsirt.org/vuln/cve-2025-22009 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>regulator: dummy: force synchronous probing</p> <p>Sometimes I get a NULL pointer dereference at boot time in kobject_get() with the following call stack:</p> <p>anatop_regulator_probe() devm_regulator_register() regulator_register() regulator_resolve_supply() kobject_get()</p> <p>By placing some extra BUG_ON() statements I could verify that this is raised because probing of the &#39;dummy&#39; regulator driver is not completed (&#39;dummy_regulator_rdev&#39; is still NULL).</p> <p>In the JTAG debugger I can see that dummy_regulator_probe() and anatop_regulator_probe() can be run by different kernel threads (kworker/u4:*). I haven&#39;t further investigated whether this can be changed or if there are other possibilities to force synchronization between these two probe routines. On the other hand I don&#39;t expect much boot time penalty by probing the &#39;dummy&#39; regulator synchronously.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>regulator: dummy: force synchronous probing</p> <p>Sometimes I get a NULL pointer dereference at boot time in kobject_get() with the following call stack:</p> <p>anatop_regulator_probe() devm_regulator_register() regulator_register() regulator_resolve_supply() kobject_get()</p> <p>By placing some extra BUG_ON() statements I could verify that this is raised because probing of the &#39;dummy&#39; regulator driver is not completed (&#39;dummy_regulator_rdev&#39; is still NULL).</p> <p>In the JTAG debugger I can see that dummy_regulator_probe() and anatop_regulator_probe() can be run by different kernel threads (kworker/u4:*). I haven&#39;t further investigated whether this can be changed or if there are other possibilities to force synchronization between these two probe routines. On the other hand I don&#39;t expect much boot time penalty by probing the &#39;dummy&#39; regulator synchronously.</p> https://cve.radiocsirt.org/vuln/cve-2025-22009