<?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>Wed, 27 May 2026 14:02:06 +0000</lastBuildDate>
    <item>
      <title>ce59cadb-58d8-4fb1-8f37-a2a5cd5133f8</title>
      <link>https://vulnerability.circl.lu/sighting/ce59cadb-58d8-4fb1-8f37-a2a5cd5133f8/export</link>
      <description>{"uuid": "ce59cadb-58d8-4fb1-8f37-a2a5cd5133f8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50191", "type": "seen", "source": "https://t.me/cvedetector/10171", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50191 - Ext4 Remote Filesystem Freeze Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50191 \nPublished : Nov. 8, 2024, 6:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \next4: don't set SB_RDONLY after filesystem errors  \n  \nWhen the filesystem is mounted with errors=remount-ro, we were setting  \nSB_RDONLY flag to stop all filesystem modifications. We knew this misses  \nproper locking (sb-&amp;gt;s_umount) and does not go through proper filesystem  \nremount procedure but it has been the way this worked since early ext2  \ndays and it was good enough for catastrophic situation damage  \nmitigation. Recently, syzbot has found a way (see link) to trigger  \nwarnings in filesystem freezing because the code got confused by  \nSB_RDONLY changing under its hands. Since these days we set  \nEXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all  \nfilesystem modifications, modifying SB_RDONLY shouldn't be needed. So  \nstop doing that. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-08T07:59:44.000000Z"}</description>
      <content:encoded>{"uuid": "ce59cadb-58d8-4fb1-8f37-a2a5cd5133f8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50191", "type": "seen", "source": "https://t.me/cvedetector/10171", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50191 - Ext4 Remote Filesystem Freeze Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50191 \nPublished : Nov. 8, 2024, 6:15 a.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \next4: don't set SB_RDONLY after filesystem errors  \n  \nWhen the filesystem is mounted with errors=remount-ro, we were setting  \nSB_RDONLY flag to stop all filesystem modifications. We knew this misses  \nproper locking (sb-&amp;gt;s_umount) and does not go through proper filesystem  \nremount procedure but it has been the way this worked since early ext2  \ndays and it was good enough for catastrophic situation damage  \nmitigation. Recently, syzbot has found a way (see link) to trigger  \nwarnings in filesystem freezing because the code got confused by  \nSB_RDONLY changing under its hands. Since these days we set  \nEXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all  \nfilesystem modifications, modifying SB_RDONLY shouldn't be needed. So  \nstop doing that. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-08T07:59:44.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/sighting/ce59cadb-58d8-4fb1-8f37-a2a5cd5133f8/export</guid>
      <pubDate>Fri, 08 Nov 2024 07:59:44 +0000</pubDate>
    </item>
    <item>
      <title>a7587f3b-c237-4852-bb38-14eafd144a81</title>
      <link>https://vulnerability.circl.lu/sighting/a7587f3b-c237-4852-bb38-14eafd144a81/export</link>
      <description>{"uuid": "a7587f3b-c237-4852-bb38-14eafd144a81", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-50191", "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": "a7587f3b-c237-4852-bb38-14eafd144a81", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-50191", "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/a7587f3b-c237-4852-bb38-14eafd144a81/export</guid>
      <pubDate>Wed, 03 Dec 2025 14:14:49 +0000</pubDate>
    </item>
  </channel>
</rss>
