ghsa-f3xx-63r9-v2cp
Vulnerability from github
Published
2024-10-21 18:30
Modified
2024-11-13 15:31
Details

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

resource: fix region_intersects() vs add_memory_driver_managed()

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 add_memory_driver_managed() during onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL Window X". This confuses region_intersects(), which expects all "System RAM" resources to be at the top level of iomem_resource. 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 devmem_is_allowed() 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 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+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, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() 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, region_intersects() 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 region_intersects(, IORESOURCE_SYSTEM_RAM, ),

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

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

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2024-49878"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T18:15:09Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nresource: fix region_intersects() vs add_memory_driver_managed()\n\nOn a system with CXL memory, the resource tree (/proc/iomem) related to\nCXL memory may look like something as follows.\n\n490000000-50fffffff : CXL Window 0\n  490000000-50fffffff : region0\n    490000000-50fffffff : dax0.0\n      490000000-50fffffff : System RAM (kmem)\n\nBecause drivers/dax/kmem.c calls add_memory_driver_managed() during\nonlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL\nWindow X\".  This confuses region_intersects(), which expects all \"System\nRAM\" resources to be at the top level of iomem_resource.  This can lead to\nbugs.\n\nFor example, when the following command line is executed to write some\nmemory in CXL memory range via /dev/mem,\n\n $ dd if=data of=/dev/mem bs=$((1 \u003c\u003c 10)) seek=$((0x490000000 \u003e\u003e 10)) count=1\n dd: error writing \u0027/dev/mem\u0027: Bad address\n 1+0 records in\n 0+0 records out\n 0 bytes copied, 0.0283507 s, 0.0 kB/s\n\nthe command fails as expected.  However, the error code is wrong.  It\nshould be \"Operation not permitted\" instead of \"Bad address\".  More\nseriously, the /dev/mem permission checking in devmem_is_allowed() passes\nincorrectly.  Although the accessing is prevented later because ioremap()\nisn\u0027t allowed to map system RAM, it is a potential security issue.  During\ncommand executing, the following warning is reported in the kernel log for\ncalling ioremap() on system RAM.\n\n ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff\n WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d\n Call Trace:\n  memremap+0xcb/0x184\n  xlate_dev_mem_ptr+0x25/0x2f\n  write_mem+0x94/0xfb\n  vfs_write+0x128/0x26d\n  ksys_write+0xac/0xfe\n  do_syscall_64+0x9a/0xfd\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nThe details of command execution process are as follows.  In the above\nresource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a\ntop level resource.  So, region_intersects() will report no System RAM\nresources in the CXL memory region incorrectly, because it only checks the\ntop level resources.  Consequently, devmem_is_allowed() will return 1\n(allow access via /dev/mem) for CXL memory region incorrectly. \nFortunately, ioremap() doesn\u0027t allow to map System RAM and reject the\naccess.\n\nSo, region_intersects() needs to be fixed to work correctly with the\nresource tree with \"System RAM\" not at top level as above.  To fix it, if\nwe found a unmatched resource in the top level, we will continue to search\nmatched resources in its descendant resources.  So, we will not miss any\nmatched resources in resource tree anymore.\n\nIn the new implementation, an example resource tree\n\n|------------- \"CXL Window 0\" ------------|\n|-- \"System RAM\" --|\n\nwill behave similar as the following fake resource tree for\nregion_intersects(, IORESOURCE_SYSTEM_RAM, ),\n\n|-- \"System RAM\" --||-- \"CXL Window 0a\" --|\n\nWhere \"CXL Window 0a\" is part of the original \"CXL Window 0\" that\nisn\u0027t covered by \"System RAM\".",
  "id": "GHSA-f3xx-63r9-v2cp",
  "modified": "2024-11-13T15:31:36Z",
  "published": "2024-10-21T18:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49878"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/06ff97a20b8c9e9d256b0d2c3e87f78f8ccea3de"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1d5f85f1b7db79c75c9e07d6571ce2a7bdf725c4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/333fbaf6864a4ca031367eb947961a1f3484d337"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/393331e16ce205e036e58b3d8ca4ee2e635f21d9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4b90d2eb451b357681063ba4552b10b39d7ad885"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8a6fef7d22a1d952aed68584d3fcc0d018d2bdc3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/927abc5b7d6d2c2e936bec5a2f71d9512c5e72f7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b4afe4183ec77f230851ea139d91e5cf2644c68b"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.