<?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://db.gcve.eu/sightings/feed</id>
  <title>Most recent sightings.</title>
  <updated>2026-09-02T19:52:20.487879+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" 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://db.gcve.eu/sighting/69e14c82-3f8e-4c58-a4e8-6e37fcbf25df/export</id>
    <title>69e14c82-3f8e-4c58-a4e8-6e37fcbf25df</title>
    <updated>2026-09-02T19:52:20.505810+00:00</updated>
    <author>
      <name>sync_user</name>
      <uri>https://db.gcve.eu/user/sync_user</uri>
    </author>
    <content>{"uuid": "69e14c82-3f8e-4c58-a4e8-6e37fcbf25df", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "4f29edb9-4c4b-44ca-b041-9b050656b6ae", "vulnerability": "CVE-2024-57872", "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://db.gcve.eu/sighting/69e14c82-3f8e-4c58-a4e8-6e37fcbf25df/export"/>
    <published>2026-03-19T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://db.gcve.eu/sighting/43ac490a-44fd-4af4-a060-d697993ed7df/export</id>
    <title>43ac490a-44fd-4af4-a060-d697993ed7df</title>
    <updated>2026-09-02T19:52:20.507537+00:00</updated>
    <author>
      <name>sync_user</name>
      <uri>https://db.gcve.eu/user/sync_user</uri>
    </author>
    <content>{"uuid": "43ac490a-44fd-4af4-a060-d697993ed7df", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "4f29edb9-4c4b-44ca-b041-9b050656b6ae", "vulnerability": "CVE-2024-57876", "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://db.gcve.eu/sighting/43ac490a-44fd-4af4-a060-d697993ed7df/export"/>
    <published>2026-03-19T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://db.gcve.eu/sighting/e2b01dc9-90a5-4ebc-a558-5239e06c6b2a/export</id>
    <title>e2b01dc9-90a5-4ebc-a558-5239e06c6b2a</title>
    <updated>2026-09-02T19:52:20.507643+00:00</updated>
    <author>
      <name>sync_user</name>
      <uri>https://db.gcve.eu/user/sync_user</uri>
    </author>
    <content>{"uuid": "e2b01dc9-90a5-4ebc-a558-5239e06c6b2a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "4f29edb9-4c4b-44ca-b041-9b050656b6ae", "vulnerability": "CVE-2024-57875", "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://db.gcve.eu/sighting/e2b01dc9-90a5-4ebc-a558-5239e06c6b2a/export"/>
    <published>2026-03-19T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://db.gcve.eu/sighting/731e14dc-e0c5-4af8-b885-2ceaf6425c93/export</id>
    <title>731e14dc-e0c5-4af8-b885-2ceaf6425c93</title>
    <updated>2026-09-02T19:52:20.507720+00:00</updated>
    <author>
      <name>cedric</name>
      <uri>https://db.gcve.eu/user/cedric</uri>
    </author>
    <content>{"uuid": "731e14dc-e0c5-4af8-b885-2ceaf6425c93", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57872", "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://db.gcve.eu/sighting/731e14dc-e0c5-4af8-b885-2ceaf6425c93/export"/>
    <published>2025-12-03T14:14:49.267740+00:00</published>
  </entry>
  <entry>
    <id>https://db.gcve.eu/sighting/34f1f062-d0fa-491c-be97-68190e1a9563/export</id>
    <title>34f1f062-d0fa-491c-be97-68190e1a9563</title>
    <updated>2026-09-02T19:52:20.508380+00:00</updated>
    <author>
      <name>cedric</name>
      <uri>https://db.gcve.eu/user/cedric</uri>
    </author>
    <content>{"uuid": "34f1f062-d0fa-491c-be97-68190e1a9563", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57875", "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://db.gcve.eu/sighting/34f1f062-d0fa-491c-be97-68190e1a9563/export"/>
    <published>2025-12-03T14:14:49.267740+00:00</published>
  </entry>
  <entry>
    <id>https://db.gcve.eu/sighting/d2ce29f9-48db-4828-995b-fa46ac342a2b/export</id>
    <title>d2ce29f9-48db-4828-995b-fa46ac342a2b</title>
    <updated>2026-09-02T19:52:20.508458+00:00</updated>
    <author>
      <name>cedric</name>
      <uri>https://db.gcve.eu/user/cedric</uri>
    </author>
    <content>{"uuid": "d2ce29f9-48db-4828-995b-fa46ac342a2b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57874", "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://db.gcve.eu/sighting/d2ce29f9-48db-4828-995b-fa46ac342a2b/export"/>
    <published>2025-08-14T10:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://db.gcve.eu/sighting/516b96cd-f55d-49ab-870a-16b39a6ebce5/export</id>
    <title>516b96cd-f55d-49ab-870a-16b39a6ebce5</title>
    <updated>2026-09-02T19:52:20.508526+00:00</updated>
    <author>
      <name>cedric</name>
      <uri>https://db.gcve.eu/user/cedric</uri>
    </author>
    <content>{"uuid": "516b96cd-f55d-49ab-870a-16b39a6ebce5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57872", "type": "seen", "source": "https://t.me/cvedetector/15097", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-57872 - \"ufs UFS Dellocate HBA Memory Leak Vulnerability in SCSI Linux Kernel\"\", \n  \"Content\": \"CVE ID : CVE-2024-57872 \nPublished : Jan. 11, 2025, 3:15 p.m. | 42\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nscsi: ufs: pltfrm: Dellocate HBA during ufshcd_pltfrm_remove()  \n  \nThis will ensure that the scsi host is cleaned up properly using  \nscsi_host_dev_release(). Otherwise, it may lead to memory leaks. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-11T17:26:47.000000Z"}</content>
    <link href="https://db.gcve.eu/sighting/516b96cd-f55d-49ab-870a-16b39a6ebce5/export"/>
    <published>2025-01-11T17:26:47+00:00</published>
  </entry>
  <entry>
    <id>https://db.gcve.eu/sighting/31f63c6d-86d9-4e66-9882-3b25f1aa3c9f/export</id>
    <title>31f63c6d-86d9-4e66-9882-3b25f1aa3c9f</title>
    <updated>2026-09-02T19:52:20.508598+00:00</updated>
    <author>
      <name>cedric</name>
      <uri>https://db.gcve.eu/user/cedric</uri>
    </author>
    <content>{"uuid": "31f63c6d-86d9-4e66-9882-3b25f1aa3c9f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57876", "type": "seen", "source": "https://t.me/cvedetector/15095", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-57876 - Linux Kernel DRM DP MST Information Disclosure Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-57876 \nPublished : Jan. 11, 2025, 3:15 p.m. | 42\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/dp_mst: Fix resetting msg rx state after topology removal  \n  \nIf the MST topology is removed during the reception of an MST down reply  \nor MST up request sideband message, the  \ndrm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset  \nfrom one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with  \nthe reading/parsing of the message from another thread via  \ndrm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is  \npossible since the reader/parser doesn't hold any lock while accessing  \nthe reception state. This in turn can lead to a memory corruption in the  \nreader/parser as described by commit bd2fccac61b4 (\"drm/dp_mst: Fix MST  \nsideband message body length check\").  \n  \nFix the above by resetting the message reception state if needed before  \nreading/parsing a message. Another solution would be to hold the  \ndrm_dp_mst_topology_mgr::lock for the whole duration of the message  \nreception/parsing in drm_dp_mst_handle_down_rep() and  \ndrm_dp_mst_handle_up_req(), however this would require a bigger change.  \nSince the fix is also needed for stable, opting for the simpler solution  \nin this patch. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-11T17:26:43.000000Z"}</content>
    <link href="https://db.gcve.eu/sighting/31f63c6d-86d9-4e66-9882-3b25f1aa3c9f/export"/>
    <published>2025-01-11T17:26:43+00:00</published>
  </entry>
  <entry>
    <id>https://db.gcve.eu/sighting/e05cd1ae-10a6-47b2-8382-459e813ef844/export</id>
    <title>e05cd1ae-10a6-47b2-8382-459e813ef844</title>
    <updated>2026-09-02T19:52:20.508676+00:00</updated>
    <author>
      <name>cedric</name>
      <uri>https://db.gcve.eu/user/cedric</uri>
    </author>
    <content>{"uuid": "e05cd1ae-10a6-47b2-8382-459e813ef844", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57875", "type": "seen", "source": "https://t.me/cvedetector/15094", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-57875 - Linux kernel Drupal Uninitialized Pointer\", \n  \"Content\": \"CVE ID : CVE-2024-57875 \nPublished : Jan. 11, 2025, 3:15 p.m. | 42\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nblock: RCU protect disk-&amp;gt;conv_zones_bitmap  \n  \nEnsure that a disk revalidation changing the conventional zones bitmap  \nof a disk does not cause invalid memory references when using the  \ndisk_zone_is_conv() helper by RCU protecting the disk-&amp;gt;conv_zones_bitmap  \npointer.  \n  \ndisk_zone_is_conv() is modified to operate under the RCU read lock and  \nthe function disk_set_conv_zones_bitmap() is added to update a disk  \nconv_zones_bitmap pointer using rcu_replace_pointer() with the disk  \nzone_wplugs_lock spinlock held.  \n  \ndisk_free_zone_resources() is modified to call  \ndisk_update_zone_resources() with a NULL bitmap pointer to free the disk  \nconv_zones_bitmap. disk_set_conv_zones_bitmap() is also used in  \ndisk_update_zone_resources() to set the new (revalidated) bitmap and  \nfree the old one. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-11T17:26:42.000000Z"}</content>
    <link href="https://db.gcve.eu/sighting/e05cd1ae-10a6-47b2-8382-459e813ef844/export"/>
    <published>2025-01-11T17:26:42+00:00</published>
  </entry>
  <entry>
    <id>https://db.gcve.eu/sighting/2df216b9-c54a-4ded-a5f7-a107ecbb9e89/export</id>
    <title>2df216b9-c54a-4ded-a5f7-a107ecbb9e89</title>
    <updated>2026-09-02T19:52:20.508752+00:00</updated>
    <author>
      <name>cedric</name>
      <uri>https://db.gcve.eu/user/cedric</uri>
    </author>
    <content>{"uuid": "2df216b9-c54a-4ded-a5f7-a107ecbb9e89", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57874", "type": "seen", "source": "https://t.me/cvedetector/15093", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-57874 - Linux Kernel Arm64 CPU Address Control Information Leak Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-57874 \nPublished : Jan. 11, 2025, 3:15 p.m. | 42\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \narm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL  \n  \nCurrently tagged_addr_ctrl_set() doesn't initialize the temporary 'ctrl'  \nvariable, and a SETREGSET call with a length of zero will leave this  \nuninitialized. Consequently tagged_addr_ctrl_set() will consume an  \narbitrary value, potentially leaking up to 64 bits of memory from the  \nkernel stack. The read is limited to a specific slot on the stack, and  \nthe issue does not provide a write mechanism.  \n  \nAs set_tagged_addr_ctrl() only accepts values where bits [63:4] zero and  \nrejects other values, a partial SETREGSET attempt will randomly succeed  \nor fail depending on the value of the uninitialized value, and the  \nexposure is significantly limited.  \n  \nFix this by initializing the temporary value before copying the regset  \nfrom userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,  \nNT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing  \nvalue of the tagged address ctrl will be retained.  \n  \nThe NT_ARM_TAGGED_ADDR_CTRL regset is only visible in the  \nuser_aarch64_view used by a native AArch64 task to manipulate another  \nnative AArch64 task. As get_tagged_addr_ctrl() only returns an error  \nvalue when called for a compat task, tagged_addr_ctrl_get() and  \ntagged_addr_ctrl_set() should never observe an error value from  \nget_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate that  \nsuch an error would be unexpected, and error handlnig is not missing in  \neither case. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-11T17:26:41.000000Z"}</content>
    <link href="https://db.gcve.eu/sighting/2df216b9-c54a-4ded-a5f7-a107ecbb9e89/export"/>
    <published>2025-01-11T17:26:41+00:00</published>
  </entry>
</feed>
