CVE-2026-63811

What it actually does

This flaw is a Linux kernel f2fs filesystem bug in the atomic write copy-on-write read path. During an atomic write, f2fs may resolve data from the COW inode but use that inode to decide whether post-read filesystem-layer decryption is needed, even though the page being filled belongs to the original inode and should use the original inode’s encryption context. In mismatched encryption-policy cases, such as a COW inode inheriting encryption while the original file is unencrypted, the kernel can attempt fscrypt decryption using a folio whose original inode has no crypto context, causing a NULL pointer dereference/general protection fault in fscrypt_decrypt_pagecache_blocks(). The practical technical impact is local denial of service through a kernel crash or filesystem-related instability when the vulnerable f2fs atomic-write path is reachable.

Why it matters to the business

Successful exploitation can crash affected Linux systems or disrupt workloads that depend on f2fs-backed storage, especially embedded devices, mobile-derived platforms, appliances, and systems using f2fs with encryption features. Because the issue is not known to be exploited in the wild, is not in CISA KEV, and has a low EPSS score, broad internet-scale urgency is low; however, systems where untrusted users or applications can write to f2fs filesystems should treat it as a meaningful availability risk.

How an attack unfolds

An attacker needs local ability to interact with an affected f2fs filesystem and trigger atomic-write behavior on files whose encryption state can differ from the temporary COW inode used internally by f2fs. The attacker prepares or identifies a situation where the original file is not using the same fscrypt context as the COW inode, then performs writes that drive f2fs_write_begin() through the atomic-write COW path. The vulnerable kernel resolves the physical block from the COW inode but incorrectly bases the read bio’s post-read decryption handling on the COW inode rather than the original inode. When asynchronous post-read work runs, fscrypt_decrypt_pagecache_blocks() operates on the original inode’s page cache folio, finds no valid crypto context, and dereferences a NULL pointer. This can produce an Oops, general protection fault, or panic depending on kernel configuration, causing denial of service.

How to fix it

Upgrade to a Linux kernel build that includes the f2fs fix for reading COW data using the original inode during atomic writes. Where vendor fixed kernel versions are available, deploy the vendor-provided kernel update rather than attempting a partial workaround. If immediate patching is not possible, reduce exposure by limiting local shell/container/user access to systems using f2fs, avoiding untrusted workloads on f2fs-backed storage, disabling or avoiding f2fs atomic-write functionality where feasible, and reviewing use of fscrypt/test_dummy_encryption or mixed encryption-policy scenarios on f2fs. Consider remounting or migrating highly exposed writable f2fs filesystems if availability requirements are strict and patching is delayed.

How to confirm the fix worked

Confirm the running kernel includes the upstream/vendor f2fs change that removes use of the COW inode for the page read crypto context during atomic writes. Validate by checking the installed kernel package version against the distribution vendor advisory or by verifying the patched f2fs source behavior: f2fs_submit_page_read() in the atomic-write write-begin path should use the original inode for post-read crypto decisions after the COW block address has been resolved. On test systems only, reproduce the previously vulnerable encryption-policy mismatch scenario and verify atomic writes no longer generate Oops, KASAN NULL pointer dereference reports, or crashes in fscrypt_decrypt_pagecache_blocks(). Also confirm no production systems continue booting older vulnerable kernel images.

Typical attack path

1. Obtain local code execution or an application-level path that can perform writes to an affected f2fs filesystem.
2. Create or target a file whose encryption context differs from the temporary COW inode created for atomic-write handling.
3. Trigger f2fs atomic-write copy-on-write behavior against the target file.
4. Cause the kernel to submit a read for the already-resolved COW block while selecting the wrong inode for post-read crypto handling.
5. Wait for f2fs post-read work to process the bio and call fscrypt decryption against a folio whose original inode lacks the expected crypto context.
6. Induce a kernel Oops, general protection fault, or panic, resulting in denial of service.

How to detect it

Look for evidence of kernel crashes or warnings during f2fs post-read or fscrypt processing. Primary sources are kernel logs, persistent journal entries, serial console logs, crash dumps, kdump/vmcore artifacts, hypervisor reset telemetry, and device watchdog reset logs. Search for Oops, general protection fault, NULL pointer dereference, KASAN reports, or panic messages with stack traces containing fscrypt_decrypt_pagecache_blocks(), fscrypt_decrypt_bio(), f2fs_post_read_work(), f2fs_submit_page_read(), f2fs_write_begin(), or f2fs_post_read_wq. Correlate crashes with recent writes to f2fs-mounted filesystems, use of atomic writes, fscrypt policy changes, test_dummy_encryption, or creation/use of files with differing encryption-policy histories. Because exploitation does not require a network callback or stable malware artifact, detection is primarily crash-forensic rather than IOC-based.

• fscrypt_decrypt_pagecache_blocks
• fscrypt_decrypt_bio
• f2fs_post_read_work
• f2fs_post_read_wq
• f2fs_submit_page_read
• f2fs_write_begin
• KASAN: null-ptr-deref
• Oops: general protection fault
• general protection fault, probably for non-canonical address
• Workqueue: f2fs_post_read_wq f2fs_post_read_work
• RIP: 0010:fscrypt_decrypt_pagecache_blocks
• test_dummy_encryption

What your security team should do

• Inventory Linux systems using f2fs, prioritizing embedded, mobile-derived, appliance, container-host, and edge systems where local users or untrusted workloads can write to f2fs filesystems.
• Patch affected kernels through the OS or device vendor as soon as practical, with higher priority for multi-user systems and systems with untrusted local code execution paths.
• Review kernel logs for prior crashes involving fscrypt_decrypt_pagecache_blocks, f2fs_post_read_work, fscrypt_decrypt_bio, or f2fs atomic-write activity.
• Restrict untrusted local access to f2fs-backed filesystems until patched, including container bind mounts, application upload paths, and writable shared directories.
• Ensure crash dump collection, persistent journaling, and kernel panic telemetry are enabled so filesystem-triggered crashes are captured for investigation.
• Track vendor advisories for exact fixed kernel packages because fixed versions were not provided in the input data and may vary by distribution or device vendor.