https://vulnerability.circl.lu Contains only the most 10 recent sightings. http://www.rssboard.org/rss-specification python-feedgen en Wed, 10 Jun 2026 05:37:27 +0000 https://vulnerability.circl.lu/sighting/40444c38-7596-4d3e-8767-9bf2ca7e1a82/export {"uuid": "40444c38-7596-4d3e-8767-9bf2ca7e1a82", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "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"} {"uuid": "40444c38-7596-4d3e-8767-9bf2ca7e1a82", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "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"} https://vulnerability.circl.lu/sighting/40444c38-7596-4d3e-8767-9bf2ca7e1a82/export Tue, 08 Apr 2025 14:00:04 +0000