<?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>Sat, 18 Jul 2026 10:08:37 +0000</lastBuildDate>
    <item>
      <title>dee6ce0d-21f4-4274-a2dc-bb1149b9061b</title>
      <link>https://vulnerability.circl.lu/sighting/dee6ce0d-21f4-4274-a2dc-bb1149b9061b/export</link>
      <description>{"uuid": "dee6ce0d-21f4-4274-a2dc-bb1149b9061b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-43866", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}</description>
      <content:encoded>{"uuid": "dee6ce0d-21f4-4274-a2dc-bb1149b9061b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-43866", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/sighting/dee6ce0d-21f4-4274-a2dc-bb1149b9061b/export</guid>
      <pubDate>Thu, 19 Mar 2026 00:00:00 +0000</pubDate>
    </item>
    <item>
      <title>a14e33e5-f55d-427d-b677-1efddca5bf71</title>
      <link>https://vulnerability.circl.lu/sighting/a14e33e5-f55d-427d-b677-1efddca5bf71/export</link>
      <description>{"uuid": "a14e33e5-f55d-427d-b677-1efddca5bf71", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-43863", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}</description>
      <content:encoded>{"uuid": "a14e33e5-f55d-427d-b677-1efddca5bf71", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-43863", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/sighting/a14e33e5-f55d-427d-b677-1efddca5bf71/export</guid>
      <pubDate>Wed, 03 Dec 2025 14:14:49 +0000</pubDate>
    </item>
    <item>
      <title>b63445a6-5467-4ee9-84eb-bb50f943aec2</title>
      <link>https://vulnerability.circl.lu/sighting/b63445a6-5467-4ee9-84eb-bb50f943aec2/export</link>
      <description>{"uuid": "b63445a6-5467-4ee9-84eb-bb50f943aec2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-43866", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}</description>
      <content:encoded>{"uuid": "b63445a6-5467-4ee9-84eb-bb50f943aec2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-43866", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/sighting/b63445a6-5467-4ee9-84eb-bb50f943aec2/export</guid>
      <pubDate>Wed, 03 Dec 2025 14:14:49 +0000</pubDate>
    </item>
    <item>
      <title>afbe44d1-ae2c-4b61-a59c-bb37554a3045</title>
      <link>https://vulnerability.circl.lu/sighting/afbe44d1-ae2c-4b61-a59c-bb37554a3045/export</link>
      <description>{"uuid": "afbe44d1-ae2c-4b61-a59c-bb37554a3045", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43861", "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": "afbe44d1-ae2c-4b61-a59c-bb37554a3045", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43861", "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/afbe44d1-ae2c-4b61-a59c-bb37554a3045/export</guid>
      <pubDate>Thu, 14 Aug 2025 10:00:00 +0000</pubDate>
    </item>
    <item>
      <title>fa3b4fd2-e3d0-40bc-b8cd-3717d017bb54</title>
      <link>https://vulnerability.circl.lu/sighting/fa3b4fd2-e3d0-40bc-b8cd-3717d017bb54/export</link>
      <description>{"uuid": "fa3b4fd2-e3d0-40bc-b8cd-3717d017bb54", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43867", "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": "fa3b4fd2-e3d0-40bc-b8cd-3717d017bb54", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43867", "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/fa3b4fd2-e3d0-40bc-b8cd-3717d017bb54/export</guid>
      <pubDate>Thu, 14 Aug 2025 10:00:00 +0000</pubDate>
    </item>
    <item>
      <title>8a5edaa1-eee8-45e0-93b7-d04833c828bc</title>
      <link>https://vulnerability.circl.lu/sighting/8a5edaa1-eee8-45e0-93b7-d04833c828bc/export</link>
      <description>{"uuid": "8a5edaa1-eee8-45e0-93b7-d04833c828bc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43869", "type": "seen", "source": "https://t.me/cvedetector/3712", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43869 - Linux Kernel Perf Event Leak Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-43869 \nPublished : Aug. 21, 2024, 1:15 a.m. | 37\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nperf: Fix event leak upon exec and file release  \n  \nThe perf pending task work is never waited upon the matching event  \nrelease. In the case of a child event, released via free_event()  \ndirectly, this can potentially result in a leaked event, such as in the  \nfollowing scenario that doesn't even require a weak IRQ work  \nimplementation to trigger:  \n  \nschedule()  \n   prepare_task_switch()  \n=======&amp;gt;   \n      perf_event_overflow()  \n         event-&amp;gt;pending_sigtrap = ...  \n         irq_work_queue(&amp;amp;event-&amp;gt;pending_irq)  \n  \n      perf_event_task_sched_out()  \n          event_sched_out()  \n              event-&amp;gt;pending_sigtrap = 0;  \n              atomic_long_inc_not_zero(&amp;amp;event-&amp;gt;refcount)  \n              task_work_add(&amp;amp;event-&amp;gt;pending_task)  \n   finish_lock_switch()  \n=======&amp;gt;   \n   perf_pending_irq()  \n      //do nothing, rely on pending task work  \n  \n  \nbegin_new_exec()  \n   perf_event_exit_task()  \n      perf_event_exit_event()  \n         // If is child event  \n         free_event()  \n            WARN(atomic_long_cmpxchg(&amp;amp;event-&amp;gt;refcount, 1, 0) != 1)  \n            // event is leaked  \n  \nSimilar scenarios can also happen with perf_event_remove_on_exec() or  \nsimply against concurrent perf_event_release().  \n  \nFix this with synchonizing against the possibly remaining pending task  \nwork while freeing the event, just like is done with remaining pending  \nIRQ work. This means that the pending task callback neither need nor  \nshould hold a reference to the event, preventing it from ever beeing  \nfreed. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T04:00:36.000000Z"}</description>
      <content:encoded>{"uuid": "8a5edaa1-eee8-45e0-93b7-d04833c828bc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43869", "type": "seen", "source": "https://t.me/cvedetector/3712", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43869 - Linux Kernel Perf Event Leak Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-43869 \nPublished : Aug. 21, 2024, 1:15 a.m. | 37\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nperf: Fix event leak upon exec and file release  \n  \nThe perf pending task work is never waited upon the matching event  \nrelease. In the case of a child event, released via free_event()  \ndirectly, this can potentially result in a leaked event, such as in the  \nfollowing scenario that doesn't even require a weak IRQ work  \nimplementation to trigger:  \n  \nschedule()  \n   prepare_task_switch()  \n=======&amp;gt;   \n      perf_event_overflow()  \n         event-&amp;gt;pending_sigtrap = ...  \n         irq_work_queue(&amp;amp;event-&amp;gt;pending_irq)  \n  \n      perf_event_task_sched_out()  \n          event_sched_out()  \n              event-&amp;gt;pending_sigtrap = 0;  \n              atomic_long_inc_not_zero(&amp;amp;event-&amp;gt;refcount)  \n              task_work_add(&amp;amp;event-&amp;gt;pending_task)  \n   finish_lock_switch()  \n=======&amp;gt;   \n   perf_pending_irq()  \n      //do nothing, rely on pending task work  \n  \n  \nbegin_new_exec()  \n   perf_event_exit_task()  \n      perf_event_exit_event()  \n         // If is child event  \n         free_event()  \n            WARN(atomic_long_cmpxchg(&amp;amp;event-&amp;gt;refcount, 1, 0) != 1)  \n            // event is leaked  \n  \nSimilar scenarios can also happen with perf_event_remove_on_exec() or  \nsimply against concurrent perf_event_release().  \n  \nFix this with synchonizing against the possibly remaining pending task  \nwork while freeing the event, just like is done with remaining pending  \nIRQ work. This means that the pending task callback neither need nor  \nshould hold a reference to the event, preventing it from ever beeing  \nfreed. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T04:00:36.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/sighting/8a5edaa1-eee8-45e0-93b7-d04833c828bc/export</guid>
      <pubDate>Wed, 21 Aug 2024 04:00:36 +0000</pubDate>
    </item>
    <item>
      <title>16529cc2-c37a-4920-8ea5-922723bdcb75</title>
      <link>https://vulnerability.circl.lu/sighting/16529cc2-c37a-4920-8ea5-922723bdcb75/export</link>
      <description>{"uuid": "16529cc2-c37a-4920-8ea5-922723bdcb75", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43863", "type": "seen", "source": "https://t.me/cvedetector/3703", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43863 - \"VMware Graphics DRM Deadlock\"\", \n  \"Content\": \"CVE ID : CVE-2024-43863 \nPublished : Aug. 21, 2024, 12:15 a.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/vmwgfx: Fix a deadlock in dma buf fence polling  \n  \nIntroduce a version of the fence ops that on release doesn't remove  \nthe fence from the pending list, and thus doesn't require a lock to  \nfix poll-&amp;gt;fence wait-&amp;gt;fence unref deadlocks.  \n  \nvmwgfx overwrites the wait callback to iterate over the list of all  \nfences and update their status, to do that it holds a lock to prevent  \nthe list modifcations from other threads. The fence destroy callback  \nboth deletes the fence and removes it from the list of pending  \nfences, for which it holds a lock.  \n  \ndma buf polling cb unrefs a fence after it's been signaled: so the poll  \ncalls the wait, which signals the fences, which are being destroyed.  \nThe destruction tries to acquire the lock on the pending fences list  \nwhich it can never get because it's held by the wait from which it  \nwas called.  \n  \nOld bug, but not a lot of userspace apps were using dma-buf polling  \ninterfaces. Fix those, in particular this fixes KDE stalls/deadlock. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T03:10:20.000000Z"}</description>
      <content:encoded>{"uuid": "16529cc2-c37a-4920-8ea5-922723bdcb75", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43863", "type": "seen", "source": "https://t.me/cvedetector/3703", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43863 - \"VMware Graphics DRM Deadlock\"\", \n  \"Content\": \"CVE ID : CVE-2024-43863 \nPublished : Aug. 21, 2024, 12:15 a.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/vmwgfx: Fix a deadlock in dma buf fence polling  \n  \nIntroduce a version of the fence ops that on release doesn't remove  \nthe fence from the pending list, and thus doesn't require a lock to  \nfix poll-&amp;gt;fence wait-&amp;gt;fence unref deadlocks.  \n  \nvmwgfx overwrites the wait callback to iterate over the list of all  \nfences and update their status, to do that it holds a lock to prevent  \nthe list modifcations from other threads. The fence destroy callback  \nboth deletes the fence and removes it from the list of pending  \nfences, for which it holds a lock.  \n  \ndma buf polling cb unrefs a fence after it's been signaled: so the poll  \ncalls the wait, which signals the fences, which are being destroyed.  \nThe destruction tries to acquire the lock on the pending fences list  \nwhich it can never get because it's held by the wait from which it  \nwas called.  \n  \nOld bug, but not a lot of userspace apps were using dma-buf polling  \ninterfaces. Fix those, in particular this fixes KDE stalls/deadlock. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T03:10:20.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/sighting/16529cc2-c37a-4920-8ea5-922723bdcb75/export</guid>
      <pubDate>Wed, 21 Aug 2024 03:10:20 +0000</pubDate>
    </item>
    <item>
      <title>37d722c5-24b9-43f9-b610-e2db185694d6</title>
      <link>https://vulnerability.circl.lu/sighting/37d722c5-24b9-43f9-b610-e2db185694d6/export</link>
      <description>{"uuid": "37d722c5-24b9-43f9-b610-e2db185694d6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43865", "type": "seen", "source": "https://t.me/cvedetector/3702", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43865 - IBM zSeries Linux FPU Stack-Based Buffer Overflow\", \n  \"Content\": \"CVE ID : CVE-2024-43865 \nPublished : Aug. 21, 2024, 12:15 a.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ns390/fpu: Re-add exception handling in load_fpu_state()  \n  \nWith the recent rewrite of the fpu code exception handling for the  \nlfpc instruction within load_fpu_state() was erroneously removed.  \n  \nAdd it again to prevent that loading invalid floating point register  \nvalues cause an unhandled specification exception. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T03:10:19.000000Z"}</description>
      <content:encoded>{"uuid": "37d722c5-24b9-43f9-b610-e2db185694d6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43865", "type": "seen", "source": "https://t.me/cvedetector/3702", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43865 - IBM zSeries Linux FPU Stack-Based Buffer Overflow\", \n  \"Content\": \"CVE ID : CVE-2024-43865 \nPublished : Aug. 21, 2024, 12:15 a.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ns390/fpu: Re-add exception handling in load_fpu_state()  \n  \nWith the recent rewrite of the fpu code exception handling for the  \nlfpc instruction within load_fpu_state() was erroneously removed.  \n  \nAdd it again to prevent that loading invalid floating point register  \nvalues cause an unhandled specification exception. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T03:10:19.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/sighting/37d722c5-24b9-43f9-b610-e2db185694d6/export</guid>
      <pubDate>Wed, 21 Aug 2024 03:10:19 +0000</pubDate>
    </item>
    <item>
      <title>d1f144f4-0ebf-432f-b37d-9f2abb4cac53</title>
      <link>https://vulnerability.circl.lu/sighting/d1f144f4-0ebf-432f-b37d-9f2abb4cac53/export</link>
      <description>{"uuid": "d1f144f4-0ebf-432f-b37d-9f2abb4cac53", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43862", "type": "seen", "source": "https://t.me/cvedetector/3700", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43862 - FSL QMC HDSL HLC Linux Kernel Deadlock Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-43862 \nPublished : Aug. 21, 2024, 12:15 a.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: wan: fsl_qmc_hdlc: Convert carrier_lock spinlock to a mutex  \n  \nThe carrier_lock spinlock protects the carrier detection. While it is  \nheld, framer_get_status() is called which in turn takes a mutex.  \nThis is not correct and can lead to a deadlock.  \n  \nA run with PROVE_LOCKING enabled detected the issue:  \n  [ BUG: Invalid wait context ]  \n  ...  \n  c204ddbc (&amp;amp;framer-&amp;gt;mutex){+.+.}-{3:3}, at: framer_get_status+0x40/0x78  \n  other info that might help us debug this:  \n  context-{4:4}  \n  2 locks held by ifconfig/146:  \n  #0: c0926a38 (rtnl_mutex){+.+.}-{3:3}, at: devinet_ioctl+0x12c/0x664  \n  #1: c2006a40 (&amp;amp;qmc_hdlc-&amp;gt;carrier_lock){....}-{2:2}, at: qmc_hdlc_framer_set_carrier+0x30/0x98  \n  \nAvoid the spinlock usage and convert carrier_lock to a mutex. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T03:10:18.000000Z"}</description>
      <content:encoded>{"uuid": "d1f144f4-0ebf-432f-b37d-9f2abb4cac53", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43862", "type": "seen", "source": "https://t.me/cvedetector/3700", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43862 - FSL QMC HDSL HLC Linux Kernel Deadlock Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-43862 \nPublished : Aug. 21, 2024, 12:15 a.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: wan: fsl_qmc_hdlc: Convert carrier_lock spinlock to a mutex  \n  \nThe carrier_lock spinlock protects the carrier detection. While it is  \nheld, framer_get_status() is called which in turn takes a mutex.  \nThis is not correct and can lead to a deadlock.  \n  \nA run with PROVE_LOCKING enabled detected the issue:  \n  [ BUG: Invalid wait context ]  \n  ...  \n  c204ddbc (&amp;amp;framer-&amp;gt;mutex){+.+.}-{3:3}, at: framer_get_status+0x40/0x78  \n  other info that might help us debug this:  \n  context-{4:4}  \n  2 locks held by ifconfig/146:  \n  #0: c0926a38 (rtnl_mutex){+.+.}-{3:3}, at: devinet_ioctl+0x12c/0x664  \n  #1: c2006a40 (&amp;amp;qmc_hdlc-&amp;gt;carrier_lock){....}-{2:2}, at: qmc_hdlc_framer_set_carrier+0x30/0x98  \n  \nAvoid the spinlock usage and convert carrier_lock to a mutex. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T03:10:18.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/sighting/d1f144f4-0ebf-432f-b37d-9f2abb4cac53/export</guid>
      <pubDate>Wed, 21 Aug 2024 03:10:18 +0000</pubDate>
    </item>
    <item>
      <title>0e0e6e98-e053-439b-9dc9-19782c63c000</title>
      <link>https://vulnerability.circl.lu/sighting/0e0e6e98-e053-439b-9dc9-19782c63c000/export</link>
      <description>{"uuid": "0e0e6e98-e053-439b-9dc9-19782c63c000", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43864", "type": "seen", "source": "https://t.me/cvedetector/3701", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43864 - IBM Mellanox Linux Kernel Panic-Risk \u7528\u6236\u6001CONTEXT\u5931\u6548\u53ef\u80fd\u6027\", \n  \"Content\": \"CVE ID : CVE-2024-43864 \nPublished : Aug. 21, 2024, 12:15 a.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet/mlx5e: Fix CT entry update leaks of modify header context  \n  \nThe cited commit allocates a new modify header to replace the old  \none when updating CT entry. But if failed to allocate a new one, eg.  \nexceed the max number firmware can support, modify header will be  \nan error pointer that will trigger a panic when deallocating it. And  \nthe old modify header point is copied to old attr. When the old  \nattr is freed, the old modify header is lost.  \n  \nFix it by restoring the old attr to attr when failed to allocate a  \nnew modify header context. So when the CT entry is freed, the right  \nmodify header context will be freed. And the panic of accessing  \nerror pointer is also fixed. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T03:10:18.000000Z"}</description>
      <content:encoded>{"uuid": "0e0e6e98-e053-439b-9dc9-19782c63c000", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43864", "type": "seen", "source": "https://t.me/cvedetector/3701", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-43864 - IBM Mellanox Linux Kernel Panic-Risk \u7528\u6236\u6001CONTEXT\u5931\u6548\u53ef\u80fd\u6027\", \n  \"Content\": \"CVE ID : CVE-2024-43864 \nPublished : Aug. 21, 2024, 12:15 a.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet/mlx5e: Fix CT entry update leaks of modify header context  \n  \nThe cited commit allocates a new modify header to replace the old  \none when updating CT entry. But if failed to allocate a new one, eg.  \nexceed the max number firmware can support, modify header will be  \nan error pointer that will trigger a panic when deallocating it. And  \nthe old modify header point is copied to old attr. When the old  \nattr is freed, the old modify header is lost.  \n  \nFix it by restoring the old attr to attr when failed to allocate a  \nnew modify header context. So when the CT entry is freed, the right  \nmodify header context will be freed. And the panic of accessing  \nerror pointer is also fixed. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T03:10:18.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/sighting/0e0e6e98-e053-439b-9dc9-19782c63c000/export</guid>
      <pubDate>Wed, 21 Aug 2024 03:10:18 +0000</pubDate>
    </item>
  </channel>
</rss>
