CVE-2024-36882

What it actually does

The flaw permits page_cache_ra_order() to allocate folios without memalloc_nofs_save(), allowing direct reclaim of file-backed pages during readahead and causing deadlock in folio_lock, migrate_pages, and compaction paths under ext4 large folio workloads.

Why it matters to the business

Unpatched kernels may experience prolonged or indefinite system hangs during file I/O operations on affected filesystems, disrupting services, backups, and data transfers with high operational downtime risk on Linux servers and Android devices.

How an attack unfolds

An attacker triggers ondemand readahead via sendfile, splice, or filemap reads on ext4 with large folios; the allocation attempt enters direct reclaim and compaction while holding page locks, blocking the task and potentially hanging the system as shown in the DataXceiver call trace.

How to fix it

Upgrade the Linux kernel to commit 7629ef6dda1564098aadeef38e5fbd11ee8627c4 or later stable releases containing the memalloc_nofs_save() fix in page_cache_ra_order().

How to confirm the fix worked

Verify kernel source contains the memalloc_nofs_save() call in page_cache_ra_order(), confirm no hung_task traces referencing page_cache_ra_order during readahead, and test ext4 large folio splice workloads under memory pressure.

Typical attack path

1. Identify ext4 filesystem using large folios
2. Perform splice or sendfile read operations to invoke page_cache_async_ra
3. Force memory pressure to enter __alloc_pages_direct_compact
4. Trigger migrate_pages and folio_lock contention leading to deadlock

How to detect it

Search kernel logs for hung_task entries exceeding 120 seconds with call traces containing page_cache_ra_order, filemap_get_pages, migrate_pages_batch, and ext4_file_splice_read; correlate with sendfile or splice activity on ext4.

• INFO: task .* blocked for more than 120 seconds
• page_cache_ra_order+0x174/0x308
• filemap_splice_read
• ext4_file_splice_read
• __folio_lock
• migrate_pages_batch

What your security team should do

• Prioritize kernel upgrades on all production Linux systems using ext4 with large folios
• Monitor for hung_task_timeout messages in kernel logs
• Apply the fix within standard patch windows given low EPSS but widespread kernel exposure
• Test readahead paths in staging environments before rollout