CVE-2022-48731

What it actually does

kmemleak_scan performs an unbounded busy loop of pfn_to_online_page() calls across enormous PFN holes created by devm_memremap_pages() on ZONE_DEVICE regions, causing soft lockups.

Why it matters to the business

Systems using certain AMD APUs with amdgpu or similar drivers experience prolonged CPU stalls and potential watchdog-induced reboots during memory-leak scanning, degrading availability on affected kernels.

How an attack unfolds

An attacker with local access writes to /sys/kernel/debug/kmemleak to trigger a scan; on kernels where node_end_pfn() was inflated by a prior large devm_request_free_mem_region() allocation, the scan loop spins for tens of seconds, producing a soft lockup.

How to fix it

Upgrade the Linux kernel to a version containing commit d3533ee20e9a0e2e8f60384da7450d43d1c63d1a or later; rebuild and reboot.

How to confirm the fix worked

Confirm the commit is present in the running kernel source; measure elapsed time of a forced kmemleak scan before and after the update on an affected APU configuration.

Typical attack path

1. Load a driver that calls devm_request_free_mem_region() and devm_memremap_pages() creating a multi-terabyte PFN hole
2. Trigger kmemleak_scan via write to the kmemleak control file
3. pfn_to_online_page() is invoked repeatedly across the hole until watchdog timeout

How to detect it

Search kernel logs for 'soft lockup' messages with a stack showing kmemleak_scan calling pfn_to_online_page; correlate with recent amdgpu module load events.

• watchdog: BUG: soft lockup.*kmemleak_scan
• RIP:.*pfn_to_online_page
• Call Trace:.*kmemleak_write

What your security team should do

• Prioritize kernel upgrade on all AMD APU systems running vulnerable kernels
• Disable kmemleak at boot if immediate patching is not feasible
• Monitor for soft-lockup reports containing kmemleak_scan in production workloads