PT-2026-61127 · Linux · Linux
CVE-2026-63811
·
Published
2026-07-19
·
Updated
2026-07-19
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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, f2fs write begin() may read the
previously written data back from the COW inode:
prepare atomic write begin() locates the block in the COW inode and sets
use cow, and the read bio is then built with the COW inode:
f2fs submit page read(use cow ? F2FS I(inode)->cow inode : inode,
...);and f2fs grab read bio() decides whether to schedule fs-layer decryption
(STEP DECRYPT) for the bio based on that inode via
fscrypt inode uses fs layer 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 f2fs encrypt one page(), which keys off
fio->page->mapping->host. fscrypt decrypt pagecache blocks() 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 test dummy encryption 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 STEP DECRYPT based on the encrypted COW inode and calls
fscrypt decrypt pagecache blocks() on a folio whose host (the unencrypted
original inode) has a NULL ->i crypt info, dereferencing it:
Oops: general protection fault, probably for non-canonical address ...
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
RIP: 0010:fscrypt decrypt pagecache blocks+0xa0/0x310
Workqueue: f2fs post read wq f2fs post read work
Call Trace:
fscrypt decrypt bio+0x1eb/0x340
f2fs post read work+0xba/0x140
process one work+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 prepare atomic write begin()
via find data block(cow inode, ...); f2fs submit page read() 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 use cow flag has no
remaining consumer; drop it from f2fs write begin() and
prepare atomic write begin().
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux