<?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://db.gcve.eu</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, 30 Aug 2026 12:57:55 +0000</lastBuildDate>
    <item>
      <title>ed9d38d8-3626-4d9a-a989-2f3194daed98</title>
      <link>https://db.gcve.eu/sighting/ed9d38d8-3626-4d9a-a989-2f3194daed98/export</link>
      <description>{"uuid": "ed9d38d8-3626-4d9a-a989-2f3194daed98", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50258", "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": "ed9d38d8-3626-4d9a-a989-2f3194daed98", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50258", "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://db.gcve.eu/sighting/ed9d38d8-3626-4d9a-a989-2f3194daed98/export</guid>
      <pubDate>Wed, 03 Dec 2025 14:14:49 +0000</pubDate>
    </item>
    <item>
      <title>e1fc5cf6-a1a0-451f-9846-5bfe0bc464cd</title>
      <link>https://db.gcve.eu/sighting/e1fc5cf6-a1a0-451f-9846-5bfe0bc464cd/export</link>
      <description>{"uuid": "e1fc5cf6-a1a0-451f-9846-5bfe0bc464cd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50256", "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": "e1fc5cf6-a1a0-451f-9846-5bfe0bc464cd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50256", "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://db.gcve.eu/sighting/e1fc5cf6-a1a0-451f-9846-5bfe0bc464cd/export</guid>
      <pubDate>Wed, 03 Dec 2025 14:14:49 +0000</pubDate>
    </item>
    <item>
      <title>0626a7f5-8504-4084-8554-54ba6f138118</title>
      <link>https://db.gcve.eu/sighting/0626a7f5-8504-4084-8554-54ba6f138118/export</link>
      <description>{"uuid": "0626a7f5-8504-4084-8554-54ba6f138118", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50251", "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": "0626a7f5-8504-4084-8554-54ba6f138118", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50251", "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://db.gcve.eu/sighting/0626a7f5-8504-4084-8554-54ba6f138118/export</guid>
      <pubDate>Thu, 14 Aug 2025 10:00:00 +0000</pubDate>
    </item>
    <item>
      <title>712a589c-c5be-4db1-b79f-5eac2d0a4efe</title>
      <link>https://db.gcve.eu/sighting/712a589c-c5be-4db1-b79f-5eac2d0a4efe/export</link>
      <description>{"uuid": "712a589c-c5be-4db1-b79f-5eac2d0a4efe", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50250", "type": "seen", "source": "https://t.me/cvedetector/10333", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50250 - Linux Kernel Fsdax Data Integrity Corrupting Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50250 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nfsdax: dax_unshare_iter needs to copy entire blocks  \n  \nThe code that copies data from srcmap to iomap in dax_unshare_iter is  \nvery very broken, which bfoster's recent fsx changes have exposed.  \n  \nIf the pos and len passed to dax_file_unshare are not aligned to an  \nfsblock boundary, the iter pos and length in the _iter function will  \nreflect this unalignment.  \n  \ndax_iomap_direct_access always returns a pointer to the start of the  \nkmapped fsdax page, even if its pos argument is in the middle of that  \npage.  This is catastrophic for data integrity when iter-&amp;gt;pos is not  \naligned to a page, because daddr/saddr do not point to the same byte in  \nthe file as iter-&amp;gt;pos.  Hence we corrupt user data by copying it to the  \nwrong place.  \n  \nIf iter-&amp;gt;pos + iomap_length() in the _iter function not aligned to a  \npage, then we fail to copy a full block, and only partially populate the  \ndestination block.  This is catastrophic for data confidentiality  \nbecause we expose stale pmem contents.  \n  \nFix both of these issues by aligning copy_pos/copy_len to a page  \nboundary (remember, this is fsdax so 1 fsblock == 1 base page) so that  \nwe always copy full blocks.  \n  \nWe're not done yet -- there's no call to invalidate_inode_pages2_range,  \nso programs that have the file range mmap'd will continue accessing the  \nold memory mapping after the file metadata updates have completed.  \n  \nBe careful with the return value -- if the unshare succeeds, we still  \nneed to return the number of bytes that the iomap iter thinks we're  \noperating on. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:18:33.000000Z"}</description>
      <content:encoded>{"uuid": "712a589c-c5be-4db1-b79f-5eac2d0a4efe", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50250", "type": "seen", "source": "https://t.me/cvedetector/10333", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50250 - Linux Kernel Fsdax Data Integrity Corrupting Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50250 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nfsdax: dax_unshare_iter needs to copy entire blocks  \n  \nThe code that copies data from srcmap to iomap in dax_unshare_iter is  \nvery very broken, which bfoster's recent fsx changes have exposed.  \n  \nIf the pos and len passed to dax_file_unshare are not aligned to an  \nfsblock boundary, the iter pos and length in the _iter function will  \nreflect this unalignment.  \n  \ndax_iomap_direct_access always returns a pointer to the start of the  \nkmapped fsdax page, even if its pos argument is in the middle of that  \npage.  This is catastrophic for data integrity when iter-&amp;gt;pos is not  \naligned to a page, because daddr/saddr do not point to the same byte in  \nthe file as iter-&amp;gt;pos.  Hence we corrupt user data by copying it to the  \nwrong place.  \n  \nIf iter-&amp;gt;pos + iomap_length() in the _iter function not aligned to a  \npage, then we fail to copy a full block, and only partially populate the  \ndestination block.  This is catastrophic for data confidentiality  \nbecause we expose stale pmem contents.  \n  \nFix both of these issues by aligning copy_pos/copy_len to a page  \nboundary (remember, this is fsdax so 1 fsblock == 1 base page) so that  \nwe always copy full blocks.  \n  \nWe're not done yet -- there's no call to invalidate_inode_pages2_range,  \nso programs that have the file range mmap'd will continue accessing the  \nold memory mapping after the file metadata updates have completed.  \n  \nBe careful with the return value -- if the unshare succeeds, we still  \nneed to return the number of bytes that the iomap iter thinks we're  \noperating on. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:18:33.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/sighting/712a589c-c5be-4db1-b79f-5eac2d0a4efe/export</guid>
      <pubDate>Sat, 09 Nov 2024 13:18:33 +0000</pubDate>
    </item>
    <item>
      <title>1d775e05-cff9-495a-befd-acb25a580e8d</title>
      <link>https://db.gcve.eu/sighting/1d775e05-cff9-495a-befd-acb25a580e8d/export</link>
      <description>{"uuid": "1d775e05-cff9-495a-befd-acb25a580e8d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50252", "type": "seen", "source": "https://t.me/cvedetector/10331", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50252 - Mellanox MLXSW IPv6 Address Leak Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50252 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address  \n  \nThe device stores IPv6 addresses that are used for encapsulation in  \nlinear memory that is managed by the driver.  \n  \nChanging the remote address of an ip6gre net device never worked  \nproperly, but since cited commit the following reproducer [1] would  \nresult in a warning [2] and a memory leak [3]. The problem is that the  \nnew remote address is never added by the driver to its hash table (and  \ntherefore the device) and the old address is never removed from it.  \n  \nFix by programming the new address when the configuration of the ip6gre  \nnet device changes and removing the old one. If the address did not  \nchange, then the above would result in increasing the reference count of  \nthe address and then decreasing it.  \n  \n[1]  \n # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit  \n # ip link set dev bla type ip6gre remote 2001:db8:3::1  \n # ip link del dev bla  \n # devlink dev reload pci/0000:01:00.0  \n  \n[2]  \nWARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0  \nModules linked in:  \nCPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151  \nHardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023  \nRIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0  \n[...]  \nCall Trace:  \n   \n mlxsw_sp_router_netdevice_event+0x55f/0x1240  \n notifier_call_chain+0x5a/0xd0  \n call_netdevice_notifiers_info+0x39/0x90  \n unregister_netdevice_many_notify+0x63e/0x9d0  \n rtnl_dellink+0x16b/0x3a0  \n rtnetlink_rcv_msg+0x142/0x3f0  \n netlink_rcv_skb+0x50/0x100  \n netlink_unicast+0x242/0x390  \n netlink_sendmsg+0x1de/0x420  \n ____sys_sendmsg+0x2bd/0x320  \n ___sys_sendmsg+0x9a/0xe0  \n __sys_sendmsg+0x7a/0xd0  \n do_syscall_64+0x9e/0x1a0  \n entry_SYSCALL_64_after_hwframe+0x77/0x7f  \n  \n[3]  \nunreferenced object 0xffff898081f597a0 (size 32):  \n  comm \"ip\", pid 1626, jiffies 4294719324  \n  hex dump (first 32 bytes):  \n    20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01   ...............  \n    21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00  !Ia.............  \n  backtrace (crc fd9be911):  \n    [&amp;lt;00000000df89c55d] __kmalloc_cache_noprof+0x1da/0x260  \n    [&amp;lt;00000000ff2a1ddb] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340  \n    [&amp;lt;000000009ddd445d] mlxsw_sp_router_netdevice_event+0x47b/0x1240  \n    [&amp;lt;00000000743e7757] notifier_call_chain+0x5a/0xd0  \n    [&amp;lt;000000007c7b9e13] call_netdevice_notifiers_info+0x39/0x90  \n    [&amp;lt;000000002509645d] register_netdevice+0x5f7/0x7a0  \n    [&amp;lt;00000000c2e7d2a9] ip6gre_newlink_common.isra.0+0x65/0x130  \n    [&amp;lt;0000000087cd6d8d] ip6gre_newlink+0x72/0x120  \n    [&amp;lt;000000004df7c7cc] rtnl_newlink+0x471/0xa20  \n    [&amp;lt;0000000057ed632a] rtnetlink_rcv_msg+0x142/0x3f0  \n    [&amp;lt;0000000032e0d5b5] netlink_rcv_skb+0x50/0x100  \n    [&amp;lt;00000000908bca63] netlink_unicast+0x242/0x390  \n    [&amp;lt;00000000cdbe1c87] netlink_sendmsg+0x1de/0x420  \n    [&amp;lt;0000000011db153e] ____sys_sendmsg+0x2bd/0x320  \n    [&amp;lt;000000003b6d53eb] ___sys_sendmsg+0x9a/0xe0  \n    [&amp;lt;00000000cae27c62] __sys_sendmsg+0x7a/0xd0 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:56.000000Z"}</description>
      <content:encoded>{"uuid": "1d775e05-cff9-495a-befd-acb25a580e8d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50252", "type": "seen", "source": "https://t.me/cvedetector/10331", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50252 - Mellanox MLXSW IPv6 Address Leak Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50252 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address  \n  \nThe device stores IPv6 addresses that are used for encapsulation in  \nlinear memory that is managed by the driver.  \n  \nChanging the remote address of an ip6gre net device never worked  \nproperly, but since cited commit the following reproducer [1] would  \nresult in a warning [2] and a memory leak [3]. The problem is that the  \nnew remote address is never added by the driver to its hash table (and  \ntherefore the device) and the old address is never removed from it.  \n  \nFix by programming the new address when the configuration of the ip6gre  \nnet device changes and removing the old one. If the address did not  \nchange, then the above would result in increasing the reference count of  \nthe address and then decreasing it.  \n  \n[1]  \n # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit  \n # ip link set dev bla type ip6gre remote 2001:db8:3::1  \n # ip link del dev bla  \n # devlink dev reload pci/0000:01:00.0  \n  \n[2]  \nWARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0  \nModules linked in:  \nCPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151  \nHardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023  \nRIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0  \n[...]  \nCall Trace:  \n   \n mlxsw_sp_router_netdevice_event+0x55f/0x1240  \n notifier_call_chain+0x5a/0xd0  \n call_netdevice_notifiers_info+0x39/0x90  \n unregister_netdevice_many_notify+0x63e/0x9d0  \n rtnl_dellink+0x16b/0x3a0  \n rtnetlink_rcv_msg+0x142/0x3f0  \n netlink_rcv_skb+0x50/0x100  \n netlink_unicast+0x242/0x390  \n netlink_sendmsg+0x1de/0x420  \n ____sys_sendmsg+0x2bd/0x320  \n ___sys_sendmsg+0x9a/0xe0  \n __sys_sendmsg+0x7a/0xd0  \n do_syscall_64+0x9e/0x1a0  \n entry_SYSCALL_64_after_hwframe+0x77/0x7f  \n  \n[3]  \nunreferenced object 0xffff898081f597a0 (size 32):  \n  comm \"ip\", pid 1626, jiffies 4294719324  \n  hex dump (first 32 bytes):  \n    20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01   ...............  \n    21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00  !Ia.............  \n  backtrace (crc fd9be911):  \n    [&amp;lt;00000000df89c55d] __kmalloc_cache_noprof+0x1da/0x260  \n    [&amp;lt;00000000ff2a1ddb] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340  \n    [&amp;lt;000000009ddd445d] mlxsw_sp_router_netdevice_event+0x47b/0x1240  \n    [&amp;lt;00000000743e7757] notifier_call_chain+0x5a/0xd0  \n    [&amp;lt;000000007c7b9e13] call_netdevice_notifiers_info+0x39/0x90  \n    [&amp;lt;000000002509645d] register_netdevice+0x5f7/0x7a0  \n    [&amp;lt;00000000c2e7d2a9] ip6gre_newlink_common.isra.0+0x65/0x130  \n    [&amp;lt;0000000087cd6d8d] ip6gre_newlink+0x72/0x120  \n    [&amp;lt;000000004df7c7cc] rtnl_newlink+0x471/0xa20  \n    [&amp;lt;0000000057ed632a] rtnetlink_rcv_msg+0x142/0x3f0  \n    [&amp;lt;0000000032e0d5b5] netlink_rcv_skb+0x50/0x100  \n    [&amp;lt;00000000908bca63] netlink_unicast+0x242/0x390  \n    [&amp;lt;00000000cdbe1c87] netlink_sendmsg+0x1de/0x420  \n    [&amp;lt;0000000011db153e] ____sys_sendmsg+0x2bd/0x320  \n    [&amp;lt;000000003b6d53eb] ___sys_sendmsg+0x9a/0xe0  \n    [&amp;lt;00000000cae27c62] __sys_sendmsg+0x7a/0xd0 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:56.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/sighting/1d775e05-cff9-495a-befd-acb25a580e8d/export</guid>
      <pubDate>Sat, 09 Nov 2024 13:17:56 +0000</pubDate>
    </item>
    <item>
      <title>ad0b5f99-8bbf-4a44-9dbb-f805b5a0f5bb</title>
      <link>https://db.gcve.eu/sighting/ad0b5f99-8bbf-4a44-9dbb-f805b5a0f5bb/export</link>
      <description>{"uuid": "ad0b5f99-8bbf-4a44-9dbb-f805b5a0f5bb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50251", "type": "seen", "source": "https://t.me/cvedetector/10330", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50251 - Linux Kernel netfilter Off-By-One vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50251 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnetfilter: nft_payload: sanitize offset and length before calling skb_checksum()  \n  \nIf access to offset + length is larger than the skbuff length, then  \nskb_checksum() triggers BUG_ON().  \n  \nskb_checksum() internally subtracts the length parameter while iterating  \nover skbuff, BUG_ON(len) at the end of it checks that the expected  \nlength to be included in the checksum calculation is fully consumed. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:55.000000Z"}</description>
      <content:encoded>{"uuid": "ad0b5f99-8bbf-4a44-9dbb-f805b5a0f5bb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50251", "type": "seen", "source": "https://t.me/cvedetector/10330", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50251 - Linux Kernel netfilter Off-By-One vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50251 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnetfilter: nft_payload: sanitize offset and length before calling skb_checksum()  \n  \nIf access to offset + length is larger than the skbuff length, then  \nskb_checksum() triggers BUG_ON().  \n  \nskb_checksum() internally subtracts the length parameter while iterating  \nover skbuff, BUG_ON(len) at the end of it checks that the expected  \nlength to be included in the checksum calculation is fully consumed. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:55.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/sighting/ad0b5f99-8bbf-4a44-9dbb-f805b5a0f5bb/export</guid>
      <pubDate>Sat, 09 Nov 2024 13:17:55 +0000</pubDate>
    </item>
    <item>
      <title>0763c49e-745b-449a-95d4-ad162b3a17d7</title>
      <link>https://db.gcve.eu/sighting/0763c49e-745b-449a-95d4-ad162b3a17d7/export</link>
      <description>{"uuid": "0763c49e-745b-449a-95d4-ad162b3a17d7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50253", "type": "seen", "source": "https://t.me/cvedetector/10321", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50253 - Linux Kernel BPF Stack Overflow Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50253 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbpf: Check the validity of nr_words in bpf_iter_bits_new()  \n  \nCheck the validity of nr_words in bpf_iter_bits_new(). Without this  \ncheck, when multiplication overflow occurs for nr_bits (e.g., when  \nnr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur  \ndue to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008).  \n  \nFix it by limiting the maximum value of nr_words to 511. The value is  \nderived from the current implementation of BPF memory allocator. To  \nensure compatibility if the BPF memory allocator's size limitation  \nchanges in the future, use the helper bpf_mem_alloc_check_size() to  \ncheck whether nr_bytes is too larger. And return -E2BIG instead of  \n-ENOMEM for oversized nr_bytes. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:42.000000Z"}</description>
      <content:encoded>{"uuid": "0763c49e-745b-449a-95d4-ad162b3a17d7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50253", "type": "seen", "source": "https://t.me/cvedetector/10321", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50253 - Linux Kernel BPF Stack Overflow Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50253 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbpf: Check the validity of nr_words in bpf_iter_bits_new()  \n  \nCheck the validity of nr_words in bpf_iter_bits_new(). Without this  \ncheck, when multiplication overflow occurs for nr_bits (e.g., when  \nnr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur  \ndue to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008).  \n  \nFix it by limiting the maximum value of nr_words to 511. The value is  \nderived from the current implementation of BPF memory allocator. To  \nensure compatibility if the BPF memory allocator's size limitation  \nchanges in the future, use the helper bpf_mem_alloc_check_size() to  \ncheck whether nr_bytes is too larger. And return -E2BIG instead of  \n-ENOMEM for oversized nr_bytes. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:42.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/sighting/0763c49e-745b-449a-95d4-ad162b3a17d7/export</guid>
      <pubDate>Sat, 09 Nov 2024 13:17:42 +0000</pubDate>
    </item>
    <item>
      <title>5506c51b-2c89-49f7-93f1-7eb1810544f3</title>
      <link>https://db.gcve.eu/sighting/5506c51b-2c89-49f7-93f1-7eb1810544f3/export</link>
      <description>{"uuid": "5506c51b-2c89-49f7-93f1-7eb1810544f3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50254", "type": "seen", "source": "https://t.me/cvedetector/10320", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50254 - Linux Kernel bpf Memory Leak Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50254 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbpf: Free dynamically allocated bits in bpf_iter_bits_destroy()  \n  \nbpf_iter_bits_destroy() uses \"kit-&amp;gt;nr_bits &amp;lt;=&amp;lt;00000000c452b4ab] kmemleak_alloc+0x4b/0x80  \n [&amp;lt;0000000004e09f80] __kmalloc_node_noprof+0x480/0x5c0  \n [&amp;lt;00000000597124d6] __alloc.isra.0+0x89/0xb0  \n [&amp;lt;000000004ebfffcd] alloc_bulk+0x2af/0x720  \n [&amp;lt;00000000d9c10145] prefill_mem_cache+0x7f/0xb0  \n [&amp;lt;00000000ff9738ff] bpf_mem_alloc_init+0x3e2/0x610  \n [&amp;lt;000000008b616eac] bpf_global_ma_init+0x19/0x30  \n [&amp;lt;00000000fc473efc] do_one_initcall+0xd3/0x3c0  \n [&amp;lt;00000000ec81498c] kernel_init_freeable+0x66a/0x940  \n [&amp;lt;00000000b119f72f] kernel_init+0x20/0x160  \n [&amp;lt;00000000f11ac9a7] ret_from_fork+0x3c/0x70  \n [&amp;lt;0000000004671da4] ret_from_fork_asm+0x1a/0x30  \n  \nThat is because nr_bits will be set as zero in bpf_iter_bits_next()  \nafter all bits have been iterated.  \n  \nFix the issue by setting kit-&amp;gt;bit to kit-&amp;gt;nr_bits instead of setting  \nkit-&amp;gt;nr_bits to zero when the iteration completes in  \nbpf_iter_bits_next(). In addition, use \"!nr_bits || bits &amp;gt;= nr_bits\" to  \ncheck whether the iteration is complete and still use \"nr_bits &amp;gt; 64\" to  \nindicate whether bits are dynamically allocated. The \"!nr_bits\" check is  \nnecessary because bpf_iter_bits_new() may fail before setting  \nkit-&amp;gt;nr_bits, and this condition will stop the iteration early instead  \nof accessing the zeroed or freed kit-&amp;gt;bits.  \n  \nConsidering the initial value of kit-&amp;gt;bits is -1 and the type of  \nkit-&amp;gt;nr_bits is unsigned int, change the type of kit-&amp;gt;nr_bits to int.  \nThe potential overflow problem will be handled in the following patch. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:41.000000Z"}</description>
      <content:encoded>{"uuid": "5506c51b-2c89-49f7-93f1-7eb1810544f3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50254", "type": "seen", "source": "https://t.me/cvedetector/10320", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50254 - Linux Kernel bpf Memory Leak Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50254 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbpf: Free dynamically allocated bits in bpf_iter_bits_destroy()  \n  \nbpf_iter_bits_destroy() uses \"kit-&amp;gt;nr_bits &amp;lt;=&amp;lt;00000000c452b4ab] kmemleak_alloc+0x4b/0x80  \n [&amp;lt;0000000004e09f80] __kmalloc_node_noprof+0x480/0x5c0  \n [&amp;lt;00000000597124d6] __alloc.isra.0+0x89/0xb0  \n [&amp;lt;000000004ebfffcd] alloc_bulk+0x2af/0x720  \n [&amp;lt;00000000d9c10145] prefill_mem_cache+0x7f/0xb0  \n [&amp;lt;00000000ff9738ff] bpf_mem_alloc_init+0x3e2/0x610  \n [&amp;lt;000000008b616eac] bpf_global_ma_init+0x19/0x30  \n [&amp;lt;00000000fc473efc] do_one_initcall+0xd3/0x3c0  \n [&amp;lt;00000000ec81498c] kernel_init_freeable+0x66a/0x940  \n [&amp;lt;00000000b119f72f] kernel_init+0x20/0x160  \n [&amp;lt;00000000f11ac9a7] ret_from_fork+0x3c/0x70  \n [&amp;lt;0000000004671da4] ret_from_fork_asm+0x1a/0x30  \n  \nThat is because nr_bits will be set as zero in bpf_iter_bits_next()  \nafter all bits have been iterated.  \n  \nFix the issue by setting kit-&amp;gt;bit to kit-&amp;gt;nr_bits instead of setting  \nkit-&amp;gt;nr_bits to zero when the iteration completes in  \nbpf_iter_bits_next(). In addition, use \"!nr_bits || bits &amp;gt;= nr_bits\" to  \ncheck whether the iteration is complete and still use \"nr_bits &amp;gt; 64\" to  \nindicate whether bits are dynamically allocated. The \"!nr_bits\" check is  \nnecessary because bpf_iter_bits_new() may fail before setting  \nkit-&amp;gt;nr_bits, and this condition will stop the iteration early instead  \nof accessing the zeroed or freed kit-&amp;gt;bits.  \n  \nConsidering the initial value of kit-&amp;gt;bits is -1 and the type of  \nkit-&amp;gt;nr_bits is unsigned int, change the type of kit-&amp;gt;nr_bits to int.  \nThe potential overflow problem will be handled in the following patch. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:41.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/sighting/5506c51b-2c89-49f7-93f1-7eb1810544f3/export</guid>
      <pubDate>Sat, 09 Nov 2024 13:17:41 +0000</pubDate>
    </item>
    <item>
      <title>43b865ab-713e-4d0b-9909-fe34108b3573</title>
      <link>https://db.gcve.eu/sighting/43b865ab-713e-4d0b-9909-fe34108b3573/export</link>
      <description>{"uuid": "43b865ab-713e-4d0b-9909-fe34108b3573", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50259", "type": "seen", "source": "https://t.me/cvedetector/10318", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50259 - \"Linux Kernel Netdevsim Uninitialized String Buffer@store\"\", \n  \"Content\": \"CVE ID : CVE-2024-50259 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnetdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write()  \n  \nThis was found by a static analyzer.  \nWe should not forget the trailing zero after copy_from_user()  \nif we will further do some string operations, sscanf() in this  \ncase. Adding a trailing zero will ensure that the function  \nperforms properly. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:39.000000Z"}</description>
      <content:encoded>{"uuid": "43b865ab-713e-4d0b-9909-fe34108b3573", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50259", "type": "seen", "source": "https://t.me/cvedetector/10318", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50259 - \"Linux Kernel Netdevsim Uninitialized String Buffer@store\"\", \n  \"Content\": \"CVE ID : CVE-2024-50259 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnetdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write()  \n  \nThis was found by a static analyzer.  \nWe should not forget the trailing zero after copy_from_user()  \nif we will further do some string operations, sscanf() in this  \ncase. Adding a trailing zero will ensure that the function  \nperforms properly. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:39.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/sighting/43b865ab-713e-4d0b-9909-fe34108b3573/export</guid>
      <pubDate>Sat, 09 Nov 2024 13:17:39 +0000</pubDate>
    </item>
    <item>
      <title>01da81de-c1bd-409a-b442-cbb42a9c6d9c</title>
      <link>https://db.gcve.eu/sighting/01da81de-c1bd-409a-b442-cbb42a9c6d9c/export</link>
      <description>{"uuid": "01da81de-c1bd-409a-b442-cbb42a9c6d9c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50258", "type": "seen", "source": "https://t.me/cvedetector/10317", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50258 - Cisco Linux Kernel Stack Overflow Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50258 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: fix crash when config small gso_max_size/gso_ipv4_max_size  \n  \nConfig a small gso_max_size/gso_ipv4_max_size will lead to an underflow  \nin sk_dst_gso_max_size(), which may trigger a BUG_ON crash,  \nbecause sk-&amp;gt;sk_gso_max_size would be much bigger than device limits.  \nCall Trace:  \ntcp_write_xmit  \n    tso_segs = tcp_init_tso_segs(skb, mss_now);  \n        tcp_set_skb_tso_segs  \n            tcp_skb_pcount_set  \n                // skb-&amp;gt;len = 524288, mss_now = 8  \n                // u16 tso_segs = 524288/8 = 65535 -&amp;gt; 0  \n                tso_segs = DIV_ROUND_UP(skb-&amp;gt;len, mss_now)  \n    BUG_ON(!tso_segs)  \nAdd check for the minimum value of gso_max_size and gso_ipv4_max_size. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:36.000000Z"}</description>
      <content:encoded>{"uuid": "01da81de-c1bd-409a-b442-cbb42a9c6d9c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-50258", "type": "seen", "source": "https://t.me/cvedetector/10317", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50258 - Cisco Linux Kernel Stack Overflow Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50258 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: fix crash when config small gso_max_size/gso_ipv4_max_size  \n  \nConfig a small gso_max_size/gso_ipv4_max_size will lead to an underflow  \nin sk_dst_gso_max_size(), which may trigger a BUG_ON crash,  \nbecause sk-&amp;gt;sk_gso_max_size would be much bigger than device limits.  \nCall Trace:  \ntcp_write_xmit  \n    tso_segs = tcp_init_tso_segs(skb, mss_now);  \n        tcp_set_skb_tso_segs  \n            tcp_skb_pcount_set  \n                // skb-&amp;gt;len = 524288, mss_now = 8  \n                // u16 tso_segs = 524288/8 = 65535 -&amp;gt; 0  \n                tso_segs = DIV_ROUND_UP(skb-&amp;gt;len, mss_now)  \n    BUG_ON(!tso_segs)  \nAdd check for the minimum value of gso_max_size and gso_ipv4_max_size. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:36.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/sighting/01da81de-c1bd-409a-b442-cbb42a9c6d9c/export</guid>
      <pubDate>Sat, 09 Nov 2024 13:17:36 +0000</pubDate>
    </item>
  </channel>
</rss>
