{"uuid": "40444c38-7596-4d3e-8767-9bf2ca7e1a82", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-22009", "type": "seen", "source": "https://t.me/cvedetector/22453", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-22009 - Linux Kernel Dummy Regulator Synchronous Probing Denial of Service Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-22009 \nPublished : April 8, 2025, 9:15 a.m. | 2\u00a0hours, 10\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nregulator: dummy: force synchronous probing  \n  \nSometimes I get a NULL pointer dereference at boot time in kobject_get()  \nwith the following call stack:  \n  \nanatop_regulator_probe()  \n devm_regulator_register()  \n  regulator_register()  \n   regulator_resolve_supply()  \n    kobject_get()  \n  \nBy placing some extra BUG_ON() statements I could verify that this is  \nraised because probing of the 'dummy' regulator driver is not completed  \n('dummy_regulator_rdev' is still NULL).  \n  \nIn the JTAG debugger I can see that dummy_regulator_probe() and  \nanatop_regulator_probe() can be run by different kernel threads  \n(kworker/u4:*).  I haven't further investigated whether this can be  \nchanged or if there are other possibilities to force synchronization  \nbetween these two probe routines.  On the other hand I don't expect much  \nboot time penalty by probing the 'dummy' regulator synchronously. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Apr 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-04-08T14:00:04.000000Z"}