CVE-2024-35872

What it actually does

GUP-fast can succeed on secretmem folios because folio_is_secretmem() relies on an unreliable LRU flag check; folios in per-CPU batches or with temporarily cleared LRU flags are missed, allowing access to folios later unmapped from the direct map and causing a kernel crash on read/write.

Why it matters to the business

Linux systems using secretmem face risk of unexpected kernel crashes and denial of service; the issue affects core memory handling across many distributions, though low EPSS and lack of KEV listing indicate limited real-world exploitation urgency after 878 days.

How an attack unfolds

An attacker triggers secretmem allocation followed by a fast GUP path that bypasses the flawed LRU check, grabs the folio, and later causes a crash when the kernel attempts to access the now-unmapped folio; named threat actors have been associated with related Android kernel issues but no public exploit maturity exists for this specific flaw.

How to fix it

Upgrade the Linux kernel to the fixed commit 6564b014af92b677c1f07c44d7f5b595d589cf6e or later stable releases containing this change; rebuild and deploy updated kernels across all affected systems.

How to confirm the fix worked

Verify the running kernel contains commit 6564b014af92b677c1f07c44d7f5b595d589cf6e or equivalent backport; reproduce secretmem allocation plus GUP-fast sequence in a test environment and confirm no crash occurs.

Typical attack path

1. Trigger secretmem allocation and fault handling to place a folio in a batch without LRU flag
2. Invoke GUP-fast on the target folio before lru_add_drain runs
3. Bypass folio_is_secretmem() due to missing LRU flag
4. Obtain reference to unmapped secretmem folio
5. Perform read/write that triggers kernel crash

How to detect it

Search kernel logs and crash dumps for oops or panic entries mentioning secretmem, GUP-fast, or folio_is_secretmem around the time of any unexpected reboots; correlate with process activity that performs get_user_pages or similar operations.

What your security team should do

• Prioritize kernel updates containing 6564b014af92b677c1f07c44d7f5b595d589cf6e on all production Linux hosts
• Review secretmem usage in applications and consider disabling if not required
• Monitor kernel logs for related oops/panic messages during the update window