CVE-2022-48731
published 2024-06-20CVE-2022-48731: In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid scanning potential huge holes When using devm_request_free_mem_region()…
PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.17%
6.5th percentile
In 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
16 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.16.10-1 (bookworm) | linux 5.16.10-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 4ef589dc9b10cdcae75a2b2b0e9b2c5e8a92c378 < d3533ee20e9a0e2e8f60384da7450d43d1c63d1a | d3533ee20e9a0e2e8f60384da7450d43d1c63d1a |
| linux | linux | >= 4ef589dc9b10cdcae75a2b2b0e9b2c5e8a92c378 < 352715593e81b917ce1b321e794549815b850134 | 352715593e81b917ce1b321e794549815b850134 |
| linux | linux | >= 4ef589dc9b10cdcae75a2b2b0e9b2c5e8a92c378 < a5389c80992f0001ee505838fe6a8b20897ce96e | a5389c80992f0001ee505838fe6a8b20897ce96e |
| linux | linux | >= 4ef589dc9b10cdcae75a2b2b0e9b2c5e8a92c378 < cebb0aceb21ad91429617a40e3a17444fabf1529 | cebb0aceb21ad91429617a40e3a17444fabf1529 |
| linux | linux | >= 4ef589dc9b10cdcae75a2b2b0e9b2c5e8a92c378 < c10a0f877fe007021d70f9cada240f42adc2b5db | c10a0f877fe007021d70f9cada240f42adc2b5db |
| linux | linux_kernel | < 5.4.178 | 5.4.178 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.10.103-1 | 5.10.103-1 |
| linux | linux_kernel | >= 0 < 5.16.10-1 | 5.16.10-1 |
| linux | linux_kernel | >= 0 < 5.16.10-1 | 5.16.10-1 |
| linux | linux_kernel | >= 0 < 5.16.10-1 | 5.16.10-1 |
| linux | linux_kernel | >= 5.11 < 5.15.22 | 5.15.22 |
| linux | linux_kernel | >= 5.16 < 5.16.8 | 5.16.8 |
| linux | linux_kernel | >= 5.5 < 5.10.99 | 5.10.99 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: mm/kmemleak: avoid scanning potential huge holes
vendor_redhat·2024-06-20·CVSS 5.5
CVE-2022-48731 [MEDIUM] CWE-835 kernel: mm/kmemleak: avoid scanning potential huge holes
kernel: mm/kmemleak: avoid scanning potential huge holes
In 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 s
Debian
CVE-2022-48731: linux - In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak...
vendor_debian·2022·CVSS 5.5
CVE-2022-48731 [MEDIUM] CVE-2022-48731: linux - In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak...
In 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 2
GHSA
GHSA-c864-85xv-823c: In the Linux kernel, the following vulnerability has been resolved:
mm/kmemleak: avoid scanning potential huge holes
When using devm_request_free_me
ghsa_unreviewed·2024-06-20
CVE-2022-48731 [MEDIUM] CWE-667 GHSA-c864-85xv-823c: In the Linux kernel, the following vulnerability has been resolved:
mm/kmemleak: avoid scanning potential huge holes
When using devm_request_free_me
In 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
OSV
CVE-2022-48731: In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid scanning potential huge holes When using devm_request_free_mem_
osv·2024-06-20·CVSS 5.5
CVE-2022-48731 [MEDIUM] CVE-2022-48731: In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid scanning potential huge holes When using devm_request_free_mem_
In 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 2
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
https://git.kernel.org/stable/c/352715593e81b917ce1b321e794549815b850134https://git.kernel.org/stable/c/a5389c80992f0001ee505838fe6a8b20897ce96ehttps://git.kernel.org/stable/c/c10a0f877fe007021d70f9cada240f42adc2b5dbhttps://git.kernel.org/stable/c/cebb0aceb21ad91429617a40e3a17444fabf1529https://git.kernel.org/stable/c/d3533ee20e9a0e2e8f60384da7450d43d1c63d1ahttps://git.kernel.org/stable/c/352715593e81b917ce1b321e794549815b850134https://git.kernel.org/stable/c/a5389c80992f0001ee505838fe6a8b20897ce96ehttps://git.kernel.org/stable/c/c10a0f877fe007021d70f9cada240f42adc2b5dbhttps://git.kernel.org/stable/c/cebb0aceb21ad91429617a40e3a17444fabf1529https://git.kernel.org/stable/c/d3533ee20e9a0e2e8f60384da7450d43d1c63d1a
2024-06-20
Published