<?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 entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 06 Oct 2026 18:49:46 +0000</lastBuildDate>
    <item>
      <title>UBUNTU-CVE-2024-43882</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2024-43882</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 187 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: exec: Fix ToCToU between perm check and set-uid/gid usage When opening a file for exec via do_filp_open(), permission checking is done against the file&amp;#39;s metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug  7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug  7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, &amp;#34;chmod o-x,u+s target&amp;#34; makes &amp;#34;target&amp;#34; executable only by uid &amp;#34;root&amp;#34; and gid &amp;#34;cdrom&amp;#34;, while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug  7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug  7 13:16 target But racing the chmod means users without group &amp;#34;cdrom&amp;#34; membership can get the permission to execute &amp;#34;target&amp;#34; just before the ch…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 187 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: exec: Fix ToCToU between perm check and set-uid/gid usage When opening a file for exec via do_filp_open(), permission checking is done against the file&amp;#39;s metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug  7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug  7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, &amp;#34;chmod o-x,u+s target&amp;#34; makes &amp;#34;target&amp;#34; executable only by uid &amp;#34;root&amp;#34; and gid &amp;#34;cdrom&amp;#34;, while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug  7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug  7 13:16 target But racing the chmod means users without group &amp;#34;cdrom&amp;#34; membership can get the permission to execute &amp;#34;target&amp;#34; just before the ch…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2024-43882</guid>
    </item>
  </channel>
</rss>
