CVE-2024-35821

What it actually does

Race condition in UBIFS where SetPageUptodate is called before data copy in page cache writes, allowing concurrent lockless readers to observe stale page contents instead of newly written data.

Why it matters to the business

Systems using UBIFS on flash storage may experience data integrity violations during concurrent read/write operations, risking unreliable file contents and potential corruption in embedded or mobile environments with high kernel adoption.

How an attack unfolds

An attacker with local or remote access to trigger file writes while simultaneously performing reads on the same pages can exploit the window before data overwrite to observe or leverage prior page contents.

How to fix it

Update the Linux kernel to include commit 4aa554832b9dc9e66249df75b8f447d87853e12e or later stable releases containing the UBIFS fix; rebuild and deploy updated kernels across affected systems.

How to confirm the fix worked

Verify kernel source contains the moved SetPageUptodate call in ubifs_write_end(); test with concurrent read/write workloads on UBIFS to confirm no stale data exposure.

Typical attack path

1. Identify UBIFS-mounted volumes and workloads with concurrent file access
2. Trigger writes via application or network input while racing with read operations
3. Observe or exfiltrate stale data exposed due to premature uptodate flag
4. Repeat to increase probability of successful observation

How to detect it

Review system logs for unusual concurrent file access patterns around UBIFS; no public exploitation artifacts reported so focus on post-patch behavioral validation.

What your security team should do

• Apply kernel updates containing the referenced commit as highest priority for UBIFS-using systems
• Monitor for upstream stable releases and schedule phased rollouts
• Review application-level concurrency patterns on flash file systems for additional hardening