CVE-2024-50222

What it actually does

Flaw in copy_page_from_iter_atomic() triggers warning and interruptible hang when CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y on x86_32 with highmem and tmpfs huge=always, due to improper handling of local kmap limits.

Why it matters to the business

Denial-of-service risk causing system unavailability on affected debug kernel configurations; low real-world prevalence reduces urgency but still requires patching for development and highmem x86_32 environments.

How an attack unfolds

An attacker with local access triggers the buggy path via file writes on tmpfs under the specific debug kmap config, leading to a hang; no widespread remote exploitation observed despite mentions of espionage and financially motivated actors targeting other Linux kernel issues.

How to fix it

Update to fixed kernel commit 4f7ffa83fa79dd52efbaef366c850aaaae06a469 or later stable releases; avoid enabling CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP in production.

How to confirm the fix worked

Confirm kernel version includes the commit, test generic/077 xfstests on x86_32 highmem with the debug option disabled or fixed, and verify no warning or hang occurs.

Typical attack path

1. Obtain local shell on target system
2. Trigger writes to tmpfs file under huge=always with highmem x86_32 and DEBUG_KMAP_LOCAL_FORCE_MAP enabled
3. Invoke copy_page_from_iter_atomic() code path
4. Trigger kunmap_local_indexed warning and hang

How to detect it

Review kernel logs for kunmap_local_indexed warnings during writes on tmpfs; check for processes hanging in shmem_file_write_iter or generic_perform_write under the affected config.

What your security team should do

• Prioritize kernel updates on any x86_32 highmem systems using debug kmap config
• Disable CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP where possible
• Monitor for future removal of the debug option as suggested in the fix