<?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 02:39:49 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-49878 — resource: fix region_intersects() vs add_memory_driver_managed()</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-49878</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;resource: fix region_intersects() vs add_memory_driver_managed()&lt;/p&gt;
&lt;p&gt;On a system with CXL memory, the resource tree (/proc/iomem) related to
CXL memory may look like something as follows.&lt;/p&gt;
&lt;p&gt;490000000-50fffffff : CXL Window 0
  490000000-50fffffff : region0
    490000000-50fffffff : dax0.0
      490000000-50fffffff : System RAM (kmem)&lt;/p&gt;
&lt;p&gt;Because drivers/dax/kmem.c calls add_memory_driver_managed() during
onlining CXL memory, which makes &amp;#34;System RAM (kmem)&amp;#34; a descendant of &amp;#34;CXL
Window X&amp;#34;.  This confuses region_intersects(), which expects all &amp;#34;System
RAM&amp;#34; resources to be at the top level of iomem_resource.  This can lead to
bugs.&lt;/p&gt;
&lt;p&gt;For example, when the following command line is executed to write some
memory in CXL memory range via /dev/mem,&lt;/p&gt;
&lt;p&gt;$ dd if=data of=/dev/mem bs=$((1 &amp;lt;&amp;lt; 10)) seek=$((0x490000000 &amp;gt;&amp;gt; 10)) count=1
 dd: error writing &amp;#39;/dev/mem&amp;#39;: Bad address
 1+0 records in
 0+0 records out
 0 bytes copied, 0.0283507 s, 0.0 kB/s&lt;/p&gt;
&lt;p&gt;the command fails as expected.  However, the error code is wrong.  It
should be &amp;#34;Operation not permitted&amp;#34; instead of &amp;#34;Bad address&amp;#34;.  More
seriously, the /dev/mem permission checking in devmem_is_allowed() passes
incorrectly.  Although the accessing is prevented later because ioremap()
isn&amp;#39;t allowed to map system RAM, it is a potential security issue.  During
command executing, the following warning is reported in the kernel log for
calling ioremap() on system RAM.&lt;/p&gt;
&lt;p&gt;ioremap on RAM at 0x00…&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;resource: fix region_intersects() vs add_memory_driver_managed()&lt;/p&gt;
&lt;p&gt;On a system with CXL memory, the resource tree (/proc/iomem) related to
CXL memory may look like something as follows.&lt;/p&gt;
&lt;p&gt;490000000-50fffffff : CXL Window 0
  490000000-50fffffff : region0
    490000000-50fffffff : dax0.0
      490000000-50fffffff : System RAM (kmem)&lt;/p&gt;
&lt;p&gt;Because drivers/dax/kmem.c calls add_memory_driver_managed() during
onlining CXL memory, which makes &amp;#34;System RAM (kmem)&amp;#34; a descendant of &amp;#34;CXL
Window X&amp;#34;.  This confuses region_intersects(), which expects all &amp;#34;System
RAM&amp;#34; resources to be at the top level of iomem_resource.  This can lead to
bugs.&lt;/p&gt;
&lt;p&gt;For example, when the following command line is executed to write some
memory in CXL memory range via /dev/mem,&lt;/p&gt;
&lt;p&gt;$ dd if=data of=/dev/mem bs=$((1 &amp;lt;&amp;lt; 10)) seek=$((0x490000000 &amp;gt;&amp;gt; 10)) count=1
 dd: error writing &amp;#39;/dev/mem&amp;#39;: Bad address
 1+0 records in
 0+0 records out
 0 bytes copied, 0.0283507 s, 0.0 kB/s&lt;/p&gt;
&lt;p&gt;the command fails as expected.  However, the error code is wrong.  It
should be &amp;#34;Operation not permitted&amp;#34; instead of &amp;#34;Bad address&amp;#34;.  More
seriously, the /dev/mem permission checking in devmem_is_allowed() passes
incorrectly.  Although the accessing is prevented later because ioremap()
isn&amp;#39;t allowed to map system RAM, it is a potential security issue.  During
command executing, the following warning is reported in the kernel log for
calling ioremap() on system RAM.&lt;/p&gt;
&lt;p&gt;ioremap on RAM at 0x00…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-49878</guid>
    </item>
  </channel>
</rss>
