<?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>Fri, 02 Oct 2026 15:25:26 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-74485 — binfmt_misc: reject a flag character as the field delimiter</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-74485</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;binfmt_misc: reject a flag character as the field delimiter&lt;/p&gt;
&lt;p&gt;The registration string starts with a user chosen delimiter that
separates the individual fields. So that the field parsers terminate
even on a truncated string create_entry() pads the buffer with that
same delimiter:&lt;/p&gt;
&lt;p&gt;memset(buf + count, del, 8);&lt;/p&gt;
&lt;p&gt;Most fields are scanned for the delimiter with strchr()/scanarg() and
happily stop on the padding. The flags field is different: instead of
scanning for the delimiter check_special_flags() consumes the flag
characters &amp;#39;P&amp;#39;, &amp;#39;O&amp;#39;, &amp;#39;C&amp;#39; and &amp;#39;F&amp;#39; and stops at the first byte that is
none of them, relying on the trailing delimiter to end the scan.&lt;/p&gt;
&lt;p&gt;If the delimiter is itself a flag character the padding no longer acts
as a terminator. The scan swallows all eight padding bytes and keeps
reading past the end of the allocation until it hits a byte that is
not a flag character. For example registering&lt;/p&gt;
&lt;p&gt;PaPEPPxPPiP&lt;/p&gt;
&lt;p&gt;with &amp;#39;P&amp;#39; as the delimiter (name &amp;#34;a&amp;#34;, type extension, magic &amp;#34;x&amp;#34;,
interpreter &amp;#34;i&amp;#34;, empty flags) leaves the flag scan running off the end
of the buffer. The registration is rejected in the end because the
parser does not stop exactly at buf + count, but only after the out of
bounds read has already happened. With an unlucky allocation layout the
scan can walk into an unmapped page; under KASAN it is reported as a
slab out of bounds read. binfmt_misc mounts are available to
unprivileged users in a user name…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;binfmt_misc: reject a flag character as the field delimiter&lt;/p&gt;
&lt;p&gt;The registration string starts with a user chosen delimiter that
separates the individual fields. So that the field parsers terminate
even on a truncated string create_entry() pads the buffer with that
same delimiter:&lt;/p&gt;
&lt;p&gt;memset(buf + count, del, 8);&lt;/p&gt;
&lt;p&gt;Most fields are scanned for the delimiter with strchr()/scanarg() and
happily stop on the padding. The flags field is different: instead of
scanning for the delimiter check_special_flags() consumes the flag
characters &amp;#39;P&amp;#39;, &amp;#39;O&amp;#39;, &amp;#39;C&amp;#39; and &amp;#39;F&amp;#39; and stops at the first byte that is
none of them, relying on the trailing delimiter to end the scan.&lt;/p&gt;
&lt;p&gt;If the delimiter is itself a flag character the padding no longer acts
as a terminator. The scan swallows all eight padding bytes and keeps
reading past the end of the allocation until it hits a byte that is
not a flag character. For example registering&lt;/p&gt;
&lt;p&gt;PaPEPPxPPiP&lt;/p&gt;
&lt;p&gt;with &amp;#39;P&amp;#39; as the delimiter (name &amp;#34;a&amp;#34;, type extension, magic &amp;#34;x&amp;#34;,
interpreter &amp;#34;i&amp;#34;, empty flags) leaves the flag scan running off the end
of the buffer. The registration is rejected in the end because the
parser does not stop exactly at buf + count, but only after the out of
bounds read has already happened. With an unlucky allocation layout the
scan can walk into an unmapped page; under KASAN it is reported as a
slab out of bounds read. binfmt_misc mounts are available to
unprivileged users in a user name…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-74485</guid>
    </item>
  </channel>
</rss>
