GHSA-C864-85XV-823C
Vulnerability from github – Published: 2024-06-20 12:31 – Updated: 2024-10-29 21:30In the Linux kernel, the following vulnerability has been resolved:
mm/kmemleak: avoid scanning potential huge holes
When using devm_request_free_mem_region() and devm_memremap_pages() to add ZONE_DEVICE memory, if requested free mem region's end pfn were huge(e.g., 0x400000000), the node_end_pfn() will be also huge (see move_pfn_range_to_zone()). Thus it creates a huge hole between node_start_pfn() and node_end_pfn().
We found on some AMD APUs, amdkfd requested such a free mem region and created a huge hole. In such a case, following code snippet was just doing busy test_bit() looping on the huge hole.
for (pfn = start_pfn; pfn < end_pfn; pfn++) { struct page *page = pfn_to_online_page(pfn); if (!page) continue; ... }
So we got a soft lockup:
watchdog: BUG: soft lockup - CPU#6 stuck for 26s! [bash:1221] CPU: 6 PID: 1221 Comm: bash Not tainted 5.15.0-custom #1 RIP: 0010:pfn_to_online_page+0x5/0xd0 Call Trace: ? kmemleak_scan+0x16a/0x440 kmemleak_write+0x306/0x3a0 ? common_file_perm+0x72/0x170 full_proxy_write+0x5c/0x90 vfs_write+0xb9/0x260 ksys_write+0x67/0xe0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae
I did some tests with the patch.
(1) amdgpu module unloaded
before the patch:
real 0m0.976s user 0m0.000s sys 0m0.968s
after the patch:
real 0m0.981s user 0m0.000s sys 0m0.973s
(2) amdgpu module loaded
before the patch:
real 0m35.365s user 0m0.000s sys 0m35.354s
after the patch:
real 0m1.049s user 0m0.000s sys 0m1.042s
{
"affected": [],
"aliases": [
"CVE-2022-48731"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-20T12:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: avoid scanning potential huge holes\n\nWhen using devm_request_free_mem_region() and devm_memremap_pages() to\nadd ZONE_DEVICE memory, if requested free mem region\u0027s end pfn were\nhuge(e.g., 0x400000000), the node_end_pfn() will be also huge (see\nmove_pfn_range_to_zone()). Thus it creates a huge hole between\nnode_start_pfn() and node_end_pfn().\n\nWe found on some AMD APUs, amdkfd requested such a free mem region and\ncreated a huge hole. In such a case, following code snippet was just\ndoing busy test_bit() looping on the huge hole.\n\n for (pfn = start_pfn; pfn \u003c end_pfn; pfn++) {\n\tstruct page *page = pfn_to_online_page(pfn);\n\t\tif (!page)\n\t\t\tcontinue;\n\t...\n }\n\nSo we got a soft lockup:\n\n watchdog: BUG: soft lockup - CPU#6 stuck for 26s! [bash:1221]\n CPU: 6 PID: 1221 Comm: bash Not tainted 5.15.0-custom #1\n RIP: 0010:pfn_to_online_page+0x5/0xd0\n Call Trace:\n ? kmemleak_scan+0x16a/0x440\n kmemleak_write+0x306/0x3a0\n ? common_file_perm+0x72/0x170\n full_proxy_write+0x5c/0x90\n vfs_write+0xb9/0x260\n ksys_write+0x67/0xe0\n __x64_sys_write+0x1a/0x20\n do_syscall_64+0x3b/0xc0\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nI did some tests with the patch.\n\n(1) amdgpu module unloaded\n\nbefore the patch:\n\n real 0m0.976s\n user 0m0.000s\n sys 0m0.968s\n\nafter the patch:\n\n real 0m0.981s\n user 0m0.000s\n sys 0m0.973s\n\n(2) amdgpu module loaded\n\nbefore the patch:\n\n real 0m35.365s\n user 0m0.000s\n sys 0m35.354s\n\nafter the patch:\n\n real 0m1.049s\n user 0m0.000s\n sys 0m1.042s",
"id": "GHSA-c864-85xv-823c",
"modified": "2024-10-29T21:30:48Z",
"published": "2024-06-20T12:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48731"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/352715593e81b917ce1b321e794549815b850134"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5389c80992f0001ee505838fe6a8b20897ce96e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c10a0f877fe007021d70f9cada240f42adc2b5db"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cebb0aceb21ad91429617a40e3a17444fabf1529"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d3533ee20e9a0e2e8f60384da7450d43d1c63d1a"
}
],
"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"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.