<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/sightings/feed</id>
  <title>Most recent sightings.</title>
  <updated>2026-07-04T00:22:13.964898+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent sightings.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/sighting/bee9b0c1-2977-430e-8530-566250530512/export</id>
    <title>bee9b0c1-2977-430e-8530-566250530512</title>
    <updated>2026-07-04T00:22:13.994277+00:00</updated>
    <author>
      <name>Joseph Lee</name>
      <uri>https://cve.circl.lu/user/syspect</uri>
    </author>
    <content>{"uuid": "bee9b0c1-2977-430e-8530-566250530512", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-44950", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}</content>
    <link href="https://vulnerability.circl.lu/sighting/bee9b0c1-2977-430e-8530-566250530512/export"/>
    <published>2026-03-19T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/sighting/4c54dbb4-237e-4a9c-81d7-423f9045059d/export</id>
    <title>4c54dbb4-237e-4a9c-81d7-423f9045059d</title>
    <updated>2026-07-04T00:22:13.996201+00:00</updated>
    <author>
      <name>Alexandre Dulaunoy</name>
      <uri>https://cve.circl.lu/user/adulau</uri>
    </author>
    <content>{"uuid": "4c54dbb4-237e-4a9c-81d7-423f9045059d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-44950", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}</content>
    <link href="https://vulnerability.circl.lu/sighting/4c54dbb4-237e-4a9c-81d7-423f9045059d/export"/>
    <published>2025-12-03T14:14:49.267740+00:00</published>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/sighting/2a37cd11-18c8-4706-9da2-f9171e24fbef/export</id>
    <title>2a37cd11-18c8-4706-9da2-f9171e24fbef</title>
    <updated>2026-07-04T00:22:13.997168+00:00</updated>
    <author>
      <name>Alexandre Dulaunoy</name>
      <uri>https://cve.circl.lu/user/adulau</uri>
    </author>
    <content>{"uuid": "2a37cd11-18c8-4706-9da2-f9171e24fbef", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-44957", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}</content>
    <link href="https://vulnerability.circl.lu/sighting/2a37cd11-18c8-4706-9da2-f9171e24fbef/export"/>
    <published>2025-12-03T14:14:49.267740+00:00</published>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/sighting/1a5f180a-3289-4971-bcea-5effe9a264bd/export</id>
    <title>1a5f180a-3289-4971-bcea-5effe9a264bd</title>
    <updated>2026-07-04T00:22:13.997279+00:00</updated>
    <author>
      <name>Alexandre Dulaunoy</name>
      <uri>https://cve.circl.lu/user/adulau</uri>
    </author>
    <content>{"uuid": "1a5f180a-3289-4971-bcea-5effe9a264bd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-44958", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}</content>
    <link href="https://vulnerability.circl.lu/sighting/1a5f180a-3289-4971-bcea-5effe9a264bd/export"/>
    <published>2025-12-03T14:14:49.267740+00:00</published>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/sighting/6bb3323a-eba9-45dd-b823-5060228ba6db/export</id>
    <title>6bb3323a-eba9-45dd-b823-5060228ba6db</title>
    <updated>2026-07-04T00:22:13.997370+00:00</updated>
    <author>
      <name>Automation user</name>
      <uri>https://cve.circl.lu/user/automation</uri>
    </author>
    <content>{"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>
    <link href="https://vulnerability.circl.lu/sighting/6bb3323a-eba9-45dd-b823-5060228ba6db/export"/>
    <published>2025-08-14T10:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/sighting/6f85a15f-8780-4e80-b46a-215cc378db6d/export</id>
    <title>6f85a15f-8780-4e80-b46a-215cc378db6d</title>
    <updated>2026-07-04T00:22:13.998260+00:00</updated>
    <author>
      <name>Automation user</name>
      <uri>https://cve.circl.lu/user/automation</uri>
    </author>
    <content>{"uuid": "6f85a15f-8780-4e80-b46a-215cc378db6d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44954", "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>
    <link href="https://vulnerability.circl.lu/sighting/6f85a15f-8780-4e80-b46a-215cc378db6d/export"/>
    <published>2025-08-14T10:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/sighting/323ce1c8-a5dd-4805-82b0-1358dd046ddc/export</id>
    <title>323ce1c8-a5dd-4805-82b0-1358dd046ddc</title>
    <updated>2026-07-04T00:22:13.998362+00:00</updated>
    <author>
      <name>Automation user</name>
      <uri>https://cve.circl.lu/user/automation</uri>
    </author>
    <content>{"uuid": "323ce1c8-a5dd-4805-82b0-1358dd046ddc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44955", "type": "seen", "source": "https://t.me/cvedetector/4849", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44955 - AMD Display Null Pointer Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-44955 \nPublished : Sept. 4, 2024, 7:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute  \n  \n[Why]  \nWhen unplug one of monitors connected after mst hub, encounter null pointer dereference.  \n  \nIt's due to dc_sink get released immediately in early_unregister() or detect_ctx(). When  \ncommit new state which directly referring to info stored in dc_sink will cause null pointer  \ndereference.  \n  \n[how]  \nRemove redundant checking condition. Relevant condition should already be covered by checking  \nif dsc_aux is null or not. Also reset dsc_aux to NULL when the connector is disconnected. \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:57:05.000000Z"}</content>
    <link href="https://vulnerability.circl.lu/sighting/323ce1c8-a5dd-4805-82b0-1358dd046ddc/export"/>
    <published>2024-09-04T21:57:05+00:00</published>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/sighting/0fa2be01-ee51-45bb-bc3a-69a68a4e95bd/export</id>
    <title>0fa2be01-ee51-45bb-bc3a-69a68a4e95bd</title>
    <updated>2026-07-04T00:22:13.998458+00:00</updated>
    <author>
      <name>Automation user</name>
      <uri>https://cve.circl.lu/user/automation</uri>
    </author>
    <content>{"uuid": "0fa2be01-ee51-45bb-bc3a-69a68a4e95bd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44957", "type": "seen", "source": "https://t.me/cvedetector/4847", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44957 - Xen Privcmd Spinlock Race Condition\", \n  \"Content\": \"CVE ID : CVE-2024-44957 \nPublished : Sept. 4, 2024, 7:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nxen: privcmd: Switch from mutex to spinlock for irqfds  \n  \nirqfd_wakeup() gets EPOLLHUP, when it is called by  \neventfd_release() by way of wake_up_poll(&amp;amp;ctx-&amp;gt;wqh, EPOLLHUP), which  \ngets called under spin_lock_irqsave(). We can't use a mutex here as it  \nwill lead to a deadlock.  \n  \nFix it by switching over to a spin lock. \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:27.000000Z"}</content>
    <link href="https://vulnerability.circl.lu/sighting/0fa2be01-ee51-45bb-bc3a-69a68a4e95bd/export"/>
    <published>2024-09-04T21:56:27+00:00</published>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/sighting/c140a324-e857-4bb7-bee6-ea1fd9088dbe/export</id>
    <title>c140a324-e857-4bb7-bee6-ea1fd9088dbe</title>
    <updated>2026-07-04T00:22:13.998547+00:00</updated>
    <author>
      <name>Automation user</name>
      <uri>https://cve.circl.lu/user/automation</uri>
    </author>
    <content>{"uuid": "c140a324-e857-4bb7-bee6-ea1fd9088dbe", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44959", "type": "seen", "source": "https://t.me/cvedetector/4844", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44959 - Linux tracefs RCU List Corruption\", \n  \"Content\": \"CVE ID : CVE-2024-44959 \nPublished : Sept. 4, 2024, 7:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ntracefs: Use generic inode RCU for synchronizing freeing  \n  \nWith structure layout randomization enabled for 'struct inode' we need to  \navoid overlapping any of the RCU-used / initialized-only-once members,  \ne.g. i_lru or i_sb_list to not corrupt related list traversals when making  \nuse of the rcu_head.  \n  \nFor an unlucky structure layout of 'struct inode' we may end up with the  \nfollowing splat when running the ftrace selftests:  \n  \n[&amp;lt;...] list_del corruption, ffff888103ee2cb0-&amp;gt;next (tracefs_inode_cache+0x0/0x4e0 [slab object]) is NULL (prev is tracefs_inode_cache+0x78/0x4e0 [slab object])  \n[&amp;lt;...] ------------[ cut here ]------------  \n[&amp;lt;...] kernel BUG at lib/list_debug.c:54!  \n[&amp;lt;...] invalid opcode: 0000 [#1] PREEMPT SMP KASAN  \n[&amp;lt;...] CPU: 3 PID: 2550 Comm: mount Tainted: G                 N  6.8.12-grsec+ #122 ed2f536ca62f28b087b90e3cc906a8d25b3ddc65  \n[&amp;lt;...] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014  \n[&amp;lt;...] RIP: 0010:[] __list_del_entry_valid_or_report+0x138/0x3e0  \n[&amp;lt;...] Code: 48 b8 99 fb 65 f2 ff ff ff ff e9 03 5c d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff e9 33 5a d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff  0b 4c 89 e9 48 89 ea 48 89 ee 48 c7 c7 60 8f dd 89 31 c0 e8 2f  \n[&amp;lt;...] RSP: 0018:fffffe80416afaf0 EFLAGS: 00010283  \n[&amp;lt;...] RAX: 0000000000000098 RBX: ffff888103ee2cb0 RCX: 0000000000000000  \n[&amp;lt;...] RDX: ffffffff84655fe8 RSI: ffffffff89dd8b60 RDI: 0000000000000001  \n[&amp;lt;...] RBP: ffff888103ee2cb0 R08: 0000000000000001 R09: fffffbd0082d5f25  \n[&amp;lt;...] R10: fffffe80416af92f R11: 0000000000000001 R12: fdf99c16731d9b6d  \n[&amp;lt;...] R13: 0000000000000000 R14: ffff88819ad4b8b8 R15: 0000000000000000  \n[&amp;lt;...] RBX: tracefs_inode_cache+0x0/0x4e0 [slab object]  \n[&amp;lt;...] RDX: __list_del_entry_valid_or_report+0x108/0x3e0  \n[&amp;lt;...] RSI: __func__.47+0x4340/0x4400  \n[&amp;lt;...] RBP: tracefs_inode_cache+0x0/0x4e0 [slab object]  \n[&amp;lt;...] RSP: process kstack fffffe80416afaf0+0x7af0/0x8000 [mount 2550 2550]  \n[&amp;lt;...] R09: kasan shadow of process kstack fffffe80416af928+0x7928/0x8000 [mount 2550 2550]  \n[&amp;lt;...] R10: process kstack fffffe80416af92f+0x792f/0x8000 [mount 2550 2550]  \n[&amp;lt;...] R14: tracefs_inode_cache+0x78/0x4e0 [slab object]  \n[&amp;lt;...] FS:  00006dcb380c1840(0000) GS:ffff8881e0600000(0000) knlGS:0000000000000000  \n[&amp;lt;...] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  \n[&amp;lt;...] CR2: 000076ab72b30e84 CR3: 000000000b088004 CR4: 0000000000360ef0 shadow CR4: 0000000000360ef0  \n[&amp;lt;...] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  \n[&amp;lt;...] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  \n[&amp;lt;...] ASID: 0003  \n[&amp;lt;...] Stack:  \n[&amp;lt;...]  ffffffff818a2315 00000000f5c856ee ffffffff896f1840 ffff888103ee2cb0  \n[&amp;lt;...]  ffff88812b6b9750 0000000079d714b6 fffffbfff1e9280b ffffffff8f49405f  \n[&amp;lt;...]  0000000000000001 0000000000000000 ffff888104457280 ffffffff8248b392  \n[&amp;lt;...] Call Trace:  \n[&amp;lt;...]    \n[&amp;lt;...]  [] ? lock_release+0x175/0x380 fffffe80416afaf0  \n[&amp;lt;...]  [] list_lru_del+0x152/0x740 fffffe80416afb48  \n[&amp;lt;...]  [] list_lru_del_obj+0x113/0x280 fffffe80416afb88  \n[&amp;lt;...]  [] ? _atomic_dec_and_lock+0x119/0x200 fffffe80416afb90  \n[&amp;lt;...]  [] iput_final+0x1c4/0x9a0 fffffe80416afbb8  \n[&amp;lt;...]  [] dentry_unlink_inode+0x44b/0xaa0 fffffe80416afbf8  \n[&amp;lt;...]  [] __dentry_kill+0x23c/0xf00 fffffe80416afc40  \n[&amp;lt;...]  [] ? __this_cpu_preempt_check+0x1f/0xa0 fffffe80416afc48  \n[&amp;lt;...]  [] ? shrink_dentry_list+0x1c5/0x760 fffffe80416afc70  \n[&amp;lt;...]  [] ? shrink_dentry_list+0x51/0x760 fffffe80416afc78  \n[&amp;lt;...]  [] shrink_dentry_list+0x288/0x760 fffffe80416afc80  \n[&amp;lt;...]  [] shrink_dcache_sb+0x155/0x420 fffffe80416afcc8  \n[&amp;lt;...]  [] ? debug_smp_[...]", "creation_timestamp": "2024-09-04T21:56:24.000000Z"}</content>
    <link href="https://vulnerability.circl.lu/sighting/c140a324-e857-4bb7-bee6-ea1fd9088dbe/export"/>
    <published>2024-09-04T21:56:24+00:00</published>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/sighting/ff520856-7656-42a4-9b57-3407459b2f73/export</id>
    <title>ff520856-7656-42a4-9b57-3407459b2f73</title>
    <updated>2026-07-04T00:22:13.998657+00:00</updated>
    <author>
      <name>Automation user</name>
      <uri>https://cve.circl.lu/user/automation</uri>
    </author>
    <content>{"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>
    <link href="https://vulnerability.circl.lu/sighting/ff520856-7656-42a4-9b57-3407459b2f73/export"/>
    <published>2024-09-04T21:56:20+00:00</published>
  </entry>
</feed>
