https://vulnerability.circl.lu Contains only the most 10 recent sightings. http://www.rssboard.org/rss-specification python-feedgen en Wed, 27 May 2026 21:28:38 +0000 https://vulnerability.circl.lu/sighting/df290cac-ca53-498f-b3ca-71f3246ca48f/export {"uuid": "df290cac-ca53-498f-b3ca-71f3246ca48f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43882", "type": "seen", "source": "https://t.me/cvedetector/3706", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-43882 - Linux Kernel Exec Vulnerability: Executer's Privilege Escalation\", \n \"Content\": \"CVE ID : CVE-2024-43882 \nPublished : Aug. 21, 2024, 1:15 a.m. | 37\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nexec: Fix ToCToU between perm check and set-uid/gid usage \n \nWhen opening a file for exec via do_filp_open(), permission checking is \ndone against the file's metadata at that moment, and on success, a file \npointer is passed back. Much later in the execve() code path, the file \nmetadata (specifically mode, uid, and gid) is used to determine if/how \nto set the uid and gid. However, those values may have changed since the \npermissions check, meaning the execution may gain unintended privileges. \n \nFor example, if a file could change permissions from executable and not \nset-id: \n \n---------x 1 root root 16048 Aug 7 13:16 target \n \nto set-id and non-executable: \n \n---S------ 1 root root 16048 Aug 7 13:16 target \n \nit is possible to gain root privileges when execution should have been \ndisallowed. \n \nWhile this race condition is rare in real-world scenarios, it has been \nobserved (and proven exploitable) when package managers are updating \nthe setuid bits of installed programs. Such files start with being \nworld-executable but then are adjusted to be group-exec with a set-uid \nbit. For example, \"chmod o-x,u+s target\" makes \"target\" executable only \nby uid \"root\" and gid \"cdrom\", while also becoming setuid-root: \n \n-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target \n \nbecomes: \n \n-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target \n \nBut racing the chmod means users without group \"cdrom\" membership can \nget the permission to execute \"target\" just before the chmod, and when \nthe chmod finishes, the exec reaches brpm_fill_uid(), and performs the \nsetuid to root, violating the expressed authorization of \"only cdrom \ngroup members can setuid to root\". \n \nRe-check that we still have execute permissions in case the metadata \nhas changed. It would be better to keep a copy from the perm-check time, \nbut until we can do that refactoring, the least-bad option is to do a \nfull inode_permission() call (under inode lock). It is understood that \nthis is safe against dead-locks, but hardly optimal. \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:28.000000Z"} {"uuid": "df290cac-ca53-498f-b3ca-71f3246ca48f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43882", "type": "seen", "source": "https://t.me/cvedetector/3706", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-43882 - Linux Kernel Exec Vulnerability: Executer's Privilege Escalation\", \n \"Content\": \"CVE ID : CVE-2024-43882 \nPublished : Aug. 21, 2024, 1:15 a.m. | 37\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nexec: Fix ToCToU between perm check and set-uid/gid usage \n \nWhen opening a file for exec via do_filp_open(), permission checking is \ndone against the file's metadata at that moment, and on success, a file \npointer is passed back. Much later in the execve() code path, the file \nmetadata (specifically mode, uid, and gid) is used to determine if/how \nto set the uid and gid. However, those values may have changed since the \npermissions check, meaning the execution may gain unintended privileges. \n \nFor example, if a file could change permissions from executable and not \nset-id: \n \n---------x 1 root root 16048 Aug 7 13:16 target \n \nto set-id and non-executable: \n \n---S------ 1 root root 16048 Aug 7 13:16 target \n \nit is possible to gain root privileges when execution should have been \ndisallowed. \n \nWhile this race condition is rare in real-world scenarios, it has been \nobserved (and proven exploitable) when package managers are updating \nthe setuid bits of installed programs. Such files start with being \nworld-executable but then are adjusted to be group-exec with a set-uid \nbit. For example, \"chmod o-x,u+s target\" makes \"target\" executable only \nby uid \"root\" and gid \"cdrom\", while also becoming setuid-root: \n \n-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target \n \nbecomes: \n \n-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target \n \nBut racing the chmod means users without group \"cdrom\" membership can \nget the permission to execute \"target\" just before the chmod, and when \nthe chmod finishes, the exec reaches brpm_fill_uid(), and performs the \nsetuid to root, violating the expressed authorization of \"only cdrom \ngroup members can setuid to root\". \n \nRe-check that we still have execute permissions in case the metadata \nhas changed. It would be better to keep a copy from the perm-check time, \nbut until we can do that refactoring, the least-bad option is to do a \nfull inode_permission() call (under inode lock). It is understood that \nthis is safe against dead-locks, but hardly optimal. \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:28.000000Z"} https://vulnerability.circl.lu/sighting/df290cac-ca53-498f-b3ca-71f3246ca48f/export Wed, 21 Aug 2024 04:00:28 +0000 https://vulnerability.circl.lu/sighting/537dff1c-15b2-4171-adc6-3116f3a9c322/export {"uuid": "537dff1c-15b2-4171-adc6-3116f3a9c322", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43882", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"} {"uuid": "537dff1c-15b2-4171-adc6-3116f3a9c322", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-43882", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"} https://vulnerability.circl.lu/sighting/537dff1c-15b2-4171-adc6-3116f3a9c322/export Thu, 14 Aug 2025 10:00:00 +0000