Description
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().
Published: 2026-07-19
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

During atomic writes on the f2fs filesystem, the write‑begin path mistakenly uses the original inode for decryption and inline crypto when handling copy‑on‑write data. This mismatch causes the fscrypt routine to dereference a NULL crypt‑info pointer, resulting in a kernel panic. The flaw is a classic null‑pointer dereference (CWE‑476). The crash effectively denies service by rendering the system unresponsive.

Affected Systems

The vulnerability affects every Linux kernel build that enables f2fs before the patch is applied. No specific kernel versions are listed, but the defect exists across all unpatched releases that contain the f2fs code handling atomic writes and encryption. It is triggered whenever a writable f2fs partition is present and write operations occur on files encrypted with or without the f2fs COW mechanism.

Risk and Exploitability

The EPSS score is less than 1 %, indicating a very low probability of exploitation in the wild. The vulnerability is not currently listed in the CISA KEV catalog. However, the impact of a successful exploit is high— a kernel panic leads to a full denial of service. Based on the description, it is inferred that the likely attack vector is local; any process with write access to a file on an affected f2fs partition can trigger the crash. If the partition is exposed through network services, remote triggering could be possible. In the absence of a CVSS score, the crash nature itself suggests a critical severity.

Generated by OpenCVE AI on July 30, 2026 at 22:15 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the upstream patch that adds commit a41075acde0124d2f8a5f563068a5d63e8ffd57b (or any later kernel that incorporates the change).
  • If a kernel upgrade is not immediately possible, mount the f2fs partition read‑only or restrict write operations via file‑system or user permissions until the patch is applied.
  • Use SELinux, AppArmor, or container isolation to limit which processes can write to the f2fs partition, thereby reducing the attack surface.

Generated by OpenCVE AI on July 30, 2026 at 22:15 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 21 Jul 2026 00:15:00 +0000


Sun, 19 Jul 2026 12:15:00 +0000

Type Values Removed Values Added
Description 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().
Title f2fs: read COW data with the original inode during atomic write
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-07-19T12:02:13.057Z

Reserved: 2026-07-19T07:54:57.013Z

Link: CVE-2026-63811

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

Severity :

Publid Date: 2026-07-19T00:00:00Z

Links: CVE-2026-63811 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-07-30T22:30:06Z

Weaknesses