CVE-2024-49878: resource: fix region_intersects() vs add_memory_driver_managed()

Published Oct 21, 2024
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

resource: fix regionintersects() vs addmemorydrivermanaged()

On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows.

490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)

Because drivers/dax/kmem.c calls addmemorydrivermanaged() during onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL Window X". This confuses regionintersects(), which expects all "System RAM" resources to be at the top level of iomemresource. This can lead to bugs.

For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem,

$ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s

the command fails as expected. However, the error code is wrong. It should be "Operation not permitted" instead of "Bad address". More seriously, the /dev/mem permission checking in devmemisallowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn'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.

ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 ioremapcaller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlatedevmemptr+0x25/0x2f writemem+0x94/0xfb vfswrite+0x128/0x26d ksyswrite+0xac/0xfe dosyscall64+0x9a/0xfd entrySYSCALL64afterhwframe+0x4b/0x53

The details of command execution process are as follows. In the above resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a top level resource. So, regionintersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmemisallowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access.

So, regionintersects() needs to be fixed to work correctly with the resource tree with "System RAM" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore.

In the new implementation, an example resource tree

|------------- "CXL Window 0" ------------| |-- "System RAM" --|

will behave similar as the following fake resource tree for regionintersects(, IORESOURCESYSTEMRAM, ),

|-- "System RAM" --||-- "CXL Window 0a" --|

Where "CXL Window 0a" is part of the original "CXL Window 0" that isn't covered by "System RAM".

Other sources

In the Linux kernel, the following vulnerability has been resolved:

resource: fix regionintersects() vs addmemorydrivermanaged()

On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows.

490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)

Because drivers/dax/kmem.c calls addmemorydrivermanaged() during onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL Window X". This confuses regionintersects(), which expects all "System RAM" resources to be at the top level of iomemresource. This can lead to bugs.

For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem,

$ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s

the command fails as expected. However, the error code is wrong. It should be "Operation not permitted" instead of "Bad address". More seriously, the /dev/mem permission checking in devmemisallowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn'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.

ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 ioremapcaller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlatedevmemptr+0x25/0x2f writemem+0x94/0xfb vfswrite+0x128/0x26d ksyswrite+0xac/0xfe dosyscall64+0x9a/0xfd entrySYSCALL64afterhwframe+0x4b/0x53

The details of command execution process are as follows. In the above resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a top level resource. So, regionintersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmemisallowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access.

So, regionintersects() needs to be fixed to work correctly with the resource tree with "System RAM" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore.

In the new implementation, an example resource tree

|------------- "CXL Window 0" ------------| |-- "System RAM" --|

will behave similar as the following fake resource tree for regionintersects(, IORESOURCESYSTEMRAM, ),

|-- "System RAM" --||-- "CXL Window 0a" --|

Where "CXL Window 0a" is part of the original "CXL Window 0" that isn't covered by "System RAM".

NVD

This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.

Launchpad

Affected Software

8 affected componentsFixes available
Linux Linux kernel>=5.1<5.10.227
Linux Linux kernel>=5.11<5.15.168
Linux Linux kernel>=5.16<6.1.113
Linux Linux kernel>=6.2<6.6.55
Linux Linux kernel>=6.7<6.10.14
Linux Linux kernel>=6.11<6.11.3
debian/linux<=5.10.223-1
5.10.234-16.1.129-16.1.135-16.12.22-16.12.25-1
debian/linux-6.1
6.1.129-1~deb11u1

Event History

Oct 21, 2024
CVE Published
via MITRE·06:01 PM
Data Sourced
via MITRE·06:01 PM
Description
Data Sourced
via NVD·06:15 PM
RemedyDescriptionSeverityAffected Software
Data Sourced
via Red Hat·07:08 PM
DescriptionSeverityAffected Software
Feb 16, 2025
Data Sourced
via Launchpad·06:11 AM
Description
Apr 29, 2025
Data Sourced
via Ubuntu·06:26 AM
RemedyDescriptionSeverityAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2024-49878?

CVE-2024-49878 has been classified with a low severity level.

2

What systems are affected by CVE-2024-49878?

CVE-2024-49878 affects multiple versions of the Linux kernel from version 5.1 up to 6.11.

3

How do I fix CVE-2024-49878?

To fix CVE-2024-49878, update your Linux kernel to a patched version, such as 6.1.123-1 or 6.12.11-1.

4

Is there a known exploit for CVE-2024-49878?

As of now, there are no known exploits specifically targeting CVE-2024-49878.

5

What vulnerabilities does CVE-2024-49878 address?

CVE-2024-49878 addresses issues with the resource tree related to CXL memory in the Linux kernel.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203