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_region() and devm_memremap_pages() to add ZONE_DEVICE memory, if requested free mem regions 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

Weakness

The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

Affected Software

Extended Description

Locking is a type of synchronization behavior that ensures that multiple independently-operating processes or threads do not interfere with each other when accessing the same resource. All processes/threads are expected to follow the same steps for locking. If these steps are not followed precisely - or if no locking is done at all - then another process/thread could modify the shared resource in a way that is not visible or predictable to the original process. This can lead to data or memory corruption, denial of service, etc.

Potential Mitigations

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/25.html
• https://cwe.mitre.org/data/definitions/26.html
• https://cwe.mitre.org/data/definitions/27.html

References

• https://git.kernel.org/stable/c/352715593e81b917ce1b321e794549815b850134
• https://git.kernel.org/stable/c/a5389c80992f0001ee505838fe6a8b20897ce96e
• https://git.kernel.org/stable/c/c10a0f877fe007021d70f9cada240f42adc2b5db
• https://git.kernel.org/stable/c/cebb0aceb21ad91429617a40e3a17444fabf1529
• https://git.kernel.org/stable/c/d3533ee20e9a0e2e8f60384da7450d43d1c63d1a
• https://git.kernel.org/stable/c/352715593e81b917ce1b321e794549815b850134
• https://git.kernel.org/stable/c/a5389c80992f0001ee505838fe6a8b20897ce96e
• https://git.kernel.org/stable/c/c10a0f877fe007021d70f9cada240f42adc2b5db
• https://git.kernel.org/stable/c/cebb0aceb21ad91429617a40e3a17444fabf1529
• https://git.kernel.org/stable/c/d3533ee20e9a0e2e8f60384da7450d43d1c63d1a