CVE-2024-43859

What it actually does

NULL pointer dereference in fscrypt_set_bio_crypt_ctx during f2fs inode truncation because i_crypt_info remains uninitialized when f2fs_truncate is invoked via GC paths during mount and checkpoint disable.

Why it matters to the business

Kernel crashes causing denial of service on Linux systems using the f2fs filesystem, with broad exposure due to 84,236 downstream dependents; patching urgency is moderate given absence from KEV and stable EPSS.

How an attack unfolds

An attacker with local access triggers f2fs mount sequences that invoke garbage collection and inode truncation before fscrypt_file_open initializes encryption context, leading to the NULL dereference; listed threat actor campaigns involving Linux kernel uninitialized resource issues could attempt to weaponize similar paths.

How to fix it

Upgrade the Linux kernel to a version containing commit 5f04969136db674f133781626e0b692c5f2bf2f0 which relocates preallocated block truncation to f2fs_file_open after fscrypt_file_open; apply the fix across all affected stable trees.

How to confirm the fix worked

Verify the presence of commit 5f04969136db674f133781626e0b692c5f2bf2f0 in the running kernel source; confirm no NULL dereference occurs during f2fs mount/GC on encrypted volumes after the update.

Typical attack path

1. Obtain local user access on target Linux system
2. Trigger f2fs filesystem mount or checkpoint disable operations
3. Force GC and truncate code paths on encrypted inodes
4. Cause NULL dereference and kernel panic

How to detect it

Inspect kernel logs and dmesg for NULL pointer dereference panics with stack traces containing fscrypt_set_bio_crypt_ctx, f2fs_grab_read_bio, truncate_partial_data_page, f2fs_do_truncate_blocks, f2fs_gc, and f2fs_disable_checkpoint; correlate with mount and checkpoint disable events.

• Unable to handle kernel NULL pointer dereference at virtual address 0000000000000011
• fscrypt_set_bio_crypt_ctx+0x78/0x1e8
• f2fs_grab_read_bio+0x78/0x208
• truncate_partial_data_page+0x108/0x4fc
• f2fs_do_truncate_blocks+0x344/0x5f0
• f2fs_disable_checkpoint+0xc8/0x310
• f2fs_fill_super+0x14bc/0x1764

What your security team should do

• Prioritize kernel updates containing the referenced commit on all f2fs deployments
• Monitor for kernel oops involving f2fs truncation and fscrypt functions
• Restrict local unprivileged access to f2fs volumes until patched
• Test f2fs mount and GC behavior in staging environments post-update