CVE-2023-52682

What it actually does

Race condition in f2fs compressed inode handling that omits f2fs_wait_on_block_writeback during inplace updates, allowing GC-submitted page writes via meta_inode to complete after user data writes and overwrite new data with stale blocks.

Why it matters to the business

Local users can trigger silent file content corruption on f2fs volumes using compression, leading to data loss, application failures, and potential integrity violations in storage-dependent workloads.

How an attack unfolds

An attacker with local access crafts concurrent f2fs_write_single_data_page and f2fs_gc operations on a compressed file so that move_data_block submits an older page via meta_inode while an IPU path writes new data; the missing writeback wait permits the stale GC write to land after the new data, corrupting the file.

How to fix it

Upgrade the Linux kernel to a version containing commit 9bfd5ea71521d0e522ba581c6ccc5db93759c0c3 or later; rebuild and reboot with the patched f2fs module.

How to confirm the fix worked

Confirm kernel source contains the referenced commit or that f2fs_wait_on_block_writeback is invoked for compressed non-encrypted inodes in the IPU path; test by exercising concurrent GC and IPU writes on compressed files and verifying no data corruption occurs.

Typical attack path

1. Mount f2fs filesystem with compression enabled on a non-encrypted inode
2. Trigger background GC via f2fs_gc / do_garbage_collect on a target data segment
3. Perform concurrent IPU write via f2fs_write_single_data_page / f2fs_inplace_write_data
4. Allow GC thread to call f2fs_submit_page_write on the migrated block before the user write completes
5. Observe stale data overriding new data in f2fs_read_end_io

How to detect it

Inspect kernel logs for f2fs GC and writeback interleaving warnings; correlate application-level checksum or data-integrity failures on compressed f2fs files after GC activity; review dmesg and ftrace output around f2fs_submit_page_bio and f2fs_read_end_io events.

What your security team should do

• Prioritize kernel upgrade on all systems using f2fs with compression
• Audit f2fs mount options and disable compression where not required
• Monitor for post-upgrade stability and data-integrity test results