CVE-2026-63811

In the Linux kernel, the following vulnerability has been resolved:

f2fs: read COW data with the original inode during atomic write

When updating an atomic-write file, f2fswritebegin() may read the previously written data back from the COW inode: prepareatomicwritebegin() locates the block in the COW inode and sets usecow, and the read bio is then built with the COW inode:

f2fs_submit_page_read(use_cow ? F2FS_I(inode)->cow_inode : inode,
              ...);

and f2fsgrabreadbio() decides whether to schedule fs-layer decryption (STEPDECRYPT) for the bio based on that inode via fscryptinodeusesfslayer_crypto().

However, the folio being filled belongs to the original inode (folio->mapping->host == inode), and the data stored in the COW block was encrypted (or left as plaintext) using the original inode's context, not the COW inode's -- see f2fsencryptonepage(), which keys off fio->page->mapping->host. fscryptdecryptpagecacheblocks() likewise operates on folio->mapping->host.

The COW inode is created as a tmpfile in the parent directory and inherits its encryption policy from there. With testdummyencryption the newly created COW inode gets the dummy policy and becomes encrypted, while a pre-existing regular file -- created before the policy applied, e.g. already present in the on-disk image -- stays unencrypted. The read path then sets STEPDECRYPT based on the encrypted COW inode and calls fscryptdecryptpagecacheblocks() on a folio whose host (the unencrypted original inode) has a NULL ->icryptinfo, dereferencing it:

Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:fscryptdecryptpagecacheblocks+0xa0/0x310 Workqueue: f2fspostreadwq f2fspostreadwork Call Trace: fscryptdecryptbio+0x1eb/0x340 f2fspostreadwork+0xba/0x140 processonework+0x91c/0x1a40 worker_thread+0x677/0xe90 kthread+0x2bc/0x3a0

The COW inode is only needed to locate the on-disk block, and that block address is already resolved into @blkaddr by prepareatomicwrite_begin() via __finddatablock(cowinode, ...); f2fssubmitpageread() then reads from that physical @blkaddr directly, so the inode argument only selects the post-read crypto context, not which block is fetched. Reading with @inode therefore returns the same (latest, not-yet-committed) COW data, while making both the fs-layer decryption decision and the inline crypto path use the correct (original inode's) key.

With the COW inode no longer used at the read site, the usecow flag has no remaining consumer; drop it from f2fswritebegin() and prepareatomicwritebegin().