CVE-2021-47335

What it actually does

Use-after-free write during kmem_cache_destroy in f2fs_recover_fsync_data caused by multiple f2fs instances racing on the global fsync_entry_slab pointer.

Why it matters to the business

Potential kernel crashes or code execution on systems mounting f2fs filesystems; low likelihood but requires kernel updates on affected deployments, with remediation deadlines not applicable given current status.

How an attack unfolds

An attacker triggers concurrent mount operations on f2fs filesystems, causing a race condition during fsync recovery that leads to use-after-free when the slab cache is destroyed.

How to fix it

Update affected packages to the fixed commit 429e873981c0d51d509c6351605e9bb74d373064; initialize and destroy the slab cache only once during module init and exit rather than per-instance.

How to confirm the fix worked

Verify the running kernel or package contains commit 429e873981c0d51d509c6351605e9bb74d373064 and confirm no duplicate slab init/destroy paths exist in f2fs module code.

Typical attack path

1. Mount multiple f2fs instances concurrently via path_mount or equivalent
2. Trigger f2fs_fill_super which calls f2fs_recover_fsync_data
3. Race on fsync_entry_slab global pointer across instances
4. Invoke kmem_cache_destroy on already-freed cache object

How to detect it

Review kernel logs for kmem_cache_destroy or f2fs_recover_fsync_data crashes and slab UAF warnings during mount operations.

What your security team should do

• Apply the listed fixed commit to all f2fs-using kernels
• Monitor for future slab-related f2fs patches
• Limit untrusted f2fs image mounts until updated