CVE-2024-41033

What it actually does

cachestat() performs stat flushing (which may sleep) inside an RCU read-side critical section during the workingset_test_recent() recency check, violating RCU constraints in a race condition.

Why it matters to the business

Unpatched Linux systems risk kernel instability or crashes when cachestat is invoked, potentially causing denial of service; low exploit likelihood reduces urgency but kernel updates remain necessary for stability in high-traffic environments.

How an attack unfolds

An attacker invokes the cachestat syscall on memory mappings to trigger the recency check path, causing stat flushing to occur while holding an RCU read lock and inducing sleep-in-atomic or scheduler faults.

How to fix it

Upgrade the Linux kernel to the commit e2f7c76758be16f1dc32c5a82270d4f6649eedab or later stable releases that move stat flushing outside the RCU section and skip flushing in the recency check.

How to confirm the fix worked

Confirm the running kernel contains commit e2f7c76758be16f1dc32c5a82270d4f6649eedab; test cachestat under memory pressure to verify no RCU warnings appear in dmesg.

Typical attack path

1. Identify a process or container with cachestat access
2. Craft input that exercises the workingset recency path
3. Trigger cachestat concurrently with memory pressure or eviction events
4. Induce sleep during the RCU section leading to kernel fault

How to detect it

Inspect kernel logs for RCU usage warnings or sleeping-while-atomic faults mentioning cachestat or workingset_test_recent; correlate with processes calling cachestat under memory pressure.

What your security team should do

• Prioritize kernel updates on all affected systems within standard maintenance windows
• Monitor for RCU-related kernel warnings after deployment
• Restrict unprivileged cachestat use via seccomp or LSM policies where feasible