<?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>Thu, 01 Oct 2026 12:37:14 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-64294 — mm: do file ownership checks with the proper mount idmap</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-64294</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;mm: do file ownership checks with the proper mount idmap&lt;/p&gt;
&lt;p&gt;Ever since idmapped mounts were introduced, inode ownership checks (for
side-channel protection) in mincore() and madvise(MADV_PAGEOUT) were done
against the nop_mnt_idmap, which completely ignores the file&amp;#39;s mount&amp;#39;s
idmap.  This results in odd edgecases like:&lt;/p&gt;
&lt;p&gt;1) mount/bind-mount with an idmap userA:userB:1
2) userB runs an owner_or_capable() check on file that is owned by userA
on-disk/in-memory, but owned by userB after idmap translation
3) owner_or_capable() mysteriously fails as the correct idmap wasn&amp;#39;t supplied&lt;/p&gt;
&lt;p&gt;In the case of mincore/madvise MADV_PAGEOUT, this is usually benign,
because file_permission(file, MAY_WRITE) will probably succeed, as it uses
the proper idmap internally, but it does not need to be the case on e.g a
0444 file where even the owner itself doesn&amp;#39;t have permissions to write to
it.&lt;/p&gt;
&lt;p&gt;Since this is clearly not trivial to get right, introduce a
file_owner_or_capable() that can carry the correct semantics, and switch
the various users in mm to it.&lt;/p&gt;
&lt;p&gt;The issue was found by manual code inspection &amp;amp; an off-list discussion
with Jan Kara.&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;mm: do file ownership checks with the proper mount idmap&lt;/p&gt;
&lt;p&gt;Ever since idmapped mounts were introduced, inode ownership checks (for
side-channel protection) in mincore() and madvise(MADV_PAGEOUT) were done
against the nop_mnt_idmap, which completely ignores the file&amp;#39;s mount&amp;#39;s
idmap.  This results in odd edgecases like:&lt;/p&gt;
&lt;p&gt;1) mount/bind-mount with an idmap userA:userB:1
2) userB runs an owner_or_capable() check on file that is owned by userA
on-disk/in-memory, but owned by userB after idmap translation
3) owner_or_capable() mysteriously fails as the correct idmap wasn&amp;#39;t supplied&lt;/p&gt;
&lt;p&gt;In the case of mincore/madvise MADV_PAGEOUT, this is usually benign,
because file_permission(file, MAY_WRITE) will probably succeed, as it uses
the proper idmap internally, but it does not need to be the case on e.g a
0444 file where even the owner itself doesn&amp;#39;t have permissions to write to
it.&lt;/p&gt;
&lt;p&gt;Since this is clearly not trivial to get right, introduce a
file_owner_or_capable() that can carry the correct semantics, and switch
the various users in mm to it.&lt;/p&gt;
&lt;p&gt;The issue was found by manual code inspection &amp;amp; an off-list discussion
with Jan Kara.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-64294</guid>
    </item>
  </channel>
</rss>
