<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent sightings.</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent sightings.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sun, 31 May 2026 06:44:32 +0000</lastBuildDate>
    <item>
      <title>ff520856-7656-42a4-9b57-3407459b2f73</title>
      <link>https://vulnerability.circl.lu/sighting/ff520856-7656-42a4-9b57-3407459b2f73/export</link>
      <description>{"uuid": "ff520856-7656-42a4-9b57-3407459b2f73", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44952", "type": "seen", "source": "https://t.me/cvedetector/4843", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44952 - Apache Linux kernel Driver Core Device Locking Deadlock\", \n  \"Content\": \"CVE ID : CVE-2024-44952 \nPublished : Sept. 4, 2024, 7:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndriver core: Fix uevent_show() vs driver detach race  \n  \nuevent_show() wants to de-reference dev-&amp;gt;driver-&amp;gt;name. There is no clean  \nway for a device attribute to de-reference dev-&amp;gt;driver unless that  \nattribute is defined via (struct device_driver).dev_groups. Instead, the  \nanti-pattern of taking the device_lock() in the attribute handler risks  \ndeadlocks with code paths that remove device attributes while holding  \nthe lock.  \n  \nThis deadlock is typically invisible to lockdep given the device_lock()  \nis marked lockdep_set_novalidate_class(), but some subsystems allocate a  \nlocal lockdep key for @dev-&amp;gt;mutex to reveal reports of the form:  \n  \n ======================================================  \n WARNING: possible circular locking dependency detected  \n 6.10.0-rc7+ #275 Tainted: G           OE    N  \n ------------------------------------------------------  \n modprobe/2374 is trying to acquire lock:  \n ffff8c2270070de0 (kn-&amp;gt;active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220  \n  \n but task is already holding lock:  \n ffff8c22016e88f8 (&amp;amp;cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210  \n  \n which lock already depends on the new lock.  \n  \n the existing dependency chain (in reverse order) is:  \n  \n -&amp;gt; #1 (&amp;amp;cxl_root_key){+.+.}-{3:3}:  \n        __mutex_lock+0x99/0xc30  \n        uevent_show+0xac/0x130  \n        dev_attr_show+0x18/0x40  \n        sysfs_kf_seq_show+0xac/0xf0  \n        seq_read_iter+0x110/0x450  \n        vfs_read+0x25b/0x340  \n        ksys_read+0x67/0xf0  \n        do_syscall_64+0x75/0x190  \n        entry_SYSCALL_64_after_hwframe+0x76/0x7e  \n  \n -&amp;gt; #0 (kn-&amp;gt;active#6){++++}-{0:0}:  \n        __lock_acquire+0x121a/0x1fa0  \n        lock_acquire+0xd6/0x2e0  \n        kernfs_drain+0x1e9/0x200  \n        __kernfs_remove+0xde/0x220  \n        kernfs_remove_by_name_ns+0x5e/0xa0  \n        device_del+0x168/0x410  \n        device_unregister+0x13/0x60  \n        devres_release_all+0xb8/0x110  \n        device_unbind_cleanup+0xe/0x70  \n        device_release_driver_internal+0x1c7/0x210  \n        driver_detach+0x47/0x90  \n        bus_remove_driver+0x6c/0xf0  \n        cxl_acpi_exit+0xc/0x11 [cxl_acpi]  \n        __do_sys_delete_module.isra.0+0x181/0x260  \n        do_syscall_64+0x75/0x190  \n        entry_SYSCALL_64_after_hwframe+0x76/0x7e  \n  \nThe observation though is that driver objects are typically much longer  \nlived than device objects. It is reasonable to perform lockless  \nde-reference of a @driver pointer even if it is racing detach from a  \ndevice. Given the infrequency of driver unregistration, use  \nsynchronize_rcu() in module_remove_driver() to close any potential  \nraces.  It is potentially overkill to suffer synchronize_rcu() just to  \nhandle the rare module removal racing uevent_show() event.  \n  \nThanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T21:56:20.000000Z"}</description>
      <content:encoded>{"uuid": "ff520856-7656-42a4-9b57-3407459b2f73", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44952", "type": "seen", "source": "https://t.me/cvedetector/4843", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44952 - Apache Linux kernel Driver Core Device Locking Deadlock\", \n  \"Content\": \"CVE ID : CVE-2024-44952 \nPublished : Sept. 4, 2024, 7:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndriver core: Fix uevent_show() vs driver detach race  \n  \nuevent_show() wants to de-reference dev-&amp;gt;driver-&amp;gt;name. There is no clean  \nway for a device attribute to de-reference dev-&amp;gt;driver unless that  \nattribute is defined via (struct device_driver).dev_groups. Instead, the  \nanti-pattern of taking the device_lock() in the attribute handler risks  \ndeadlocks with code paths that remove device attributes while holding  \nthe lock.  \n  \nThis deadlock is typically invisible to lockdep given the device_lock()  \nis marked lockdep_set_novalidate_class(), but some subsystems allocate a  \nlocal lockdep key for @dev-&amp;gt;mutex to reveal reports of the form:  \n  \n ======================================================  \n WARNING: possible circular locking dependency detected  \n 6.10.0-rc7+ #275 Tainted: G           OE    N  \n ------------------------------------------------------  \n modprobe/2374 is trying to acquire lock:  \n ffff8c2270070de0 (kn-&amp;gt;active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220  \n  \n but task is already holding lock:  \n ffff8c22016e88f8 (&amp;amp;cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210  \n  \n which lock already depends on the new lock.  \n  \n the existing dependency chain (in reverse order) is:  \n  \n -&amp;gt; #1 (&amp;amp;cxl_root_key){+.+.}-{3:3}:  \n        __mutex_lock+0x99/0xc30  \n        uevent_show+0xac/0x130  \n        dev_attr_show+0x18/0x40  \n        sysfs_kf_seq_show+0xac/0xf0  \n        seq_read_iter+0x110/0x450  \n        vfs_read+0x25b/0x340  \n        ksys_read+0x67/0xf0  \n        do_syscall_64+0x75/0x190  \n        entry_SYSCALL_64_after_hwframe+0x76/0x7e  \n  \n -&amp;gt; #0 (kn-&amp;gt;active#6){++++}-{0:0}:  \n        __lock_acquire+0x121a/0x1fa0  \n        lock_acquire+0xd6/0x2e0  \n        kernfs_drain+0x1e9/0x200  \n        __kernfs_remove+0xde/0x220  \n        kernfs_remove_by_name_ns+0x5e/0xa0  \n        device_del+0x168/0x410  \n        device_unregister+0x13/0x60  \n        devres_release_all+0xb8/0x110  \n        device_unbind_cleanup+0xe/0x70  \n        device_release_driver_internal+0x1c7/0x210  \n        driver_detach+0x47/0x90  \n        bus_remove_driver+0x6c/0xf0  \n        cxl_acpi_exit+0xc/0x11 [cxl_acpi]  \n        __do_sys_delete_module.isra.0+0x181/0x260  \n        do_syscall_64+0x75/0x190  \n        entry_SYSCALL_64_after_hwframe+0x76/0x7e  \n  \nThe observation though is that driver objects are typically much longer  \nlived than device objects. It is reasonable to perform lockless  \nde-reference of a @driver pointer even if it is racing detach from a  \ndevice. Given the infrequency of driver unregistration, use  \nsynchronize_rcu() in module_remove_driver() to close any potential  \nraces.  It is potentially overkill to suffer synchronize_rcu() just to  \nhandle the rare module removal racing uevent_show() event.  \n  \nThanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T21:56:20.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/sighting/ff520856-7656-42a4-9b57-3407459b2f73/export</guid>
      <pubDate>Wed, 04 Sep 2024 21:56:20 +0000</pubDate>
    </item>
    <item>
      <title>6bb3323a-eba9-45dd-b823-5060228ba6db</title>
      <link>https://vulnerability.circl.lu/sighting/6bb3323a-eba9-45dd-b823-5060228ba6db/export</link>
      <description>{"uuid": "6bb3323a-eba9-45dd-b823-5060228ba6db", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44952", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}</description>
      <content:encoded>{"uuid": "6bb3323a-eba9-45dd-b823-5060228ba6db", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44952", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/sighting/6bb3323a-eba9-45dd-b823-5060228ba6db/export</guid>
      <pubDate>Thu, 14 Aug 2025 10:00:00 +0000</pubDate>
    </item>
  </channel>
</rss>
