VulnerabilityPublished 19 Jul 2026Updated 21 Oct 2026

CVE-2026-63811: Linux kernel · f2fs: read COW data with the original inode during atomic write

Affects Linux kernelSource CVE Database V5

Not known to be exploited · fixed in bcc9df992f3cbc43f2ecfe0b22e428e50f326e72 : update Linux kernel when convenient.

Data as of 26 Oct 2026, 13:47 UTC

Severity

Unrated

Rated by Threat Radar · No CVSS score from NVD or the CNA

EPSS: 0.1% chance of exploitation in 30 days – higher than 2% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in bcc9df992f3cbc43f2ecfe0b22e428e50f326e72, a92332f32a8d31a7eee47b1dc1d751cb3319908f, a41075acde0124d2f8a5f563068a5d63e8ffd57b +2

Exploitation evidence

Disclosed: evidence found.
CVE published 19 Jul 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ 591fc34e1f98b0d7eef4aa3440bfdff3c5a1cadd, < bcc9df992f3cbc43f2ecfe0b22e428e50f326e72	Fixed in bcc9df992f3cbc43f2ecfe0b22e428e50f326e72
LinuxLinux	Affected ≥ 591fc34e1f98b0d7eef4aa3440bfdff3c5a1cadd, < a92332f32a8d31a7eee47b1dc1d751cb3319908f	Fixed in a92332f32a8d31a7eee47b1dc1d751cb3319908f
LinuxLinux	Affected ≥ 591fc34e1f98b0d7eef4aa3440bfdff3c5a1cadd, < a41075acde0124d2f8a5f563068a5d63e8ffd57b	Fixed in a41075acde0124d2f8a5f563068a5d63e8ffd57b
LinuxLinux	Affected ≥ 591fc34e1f98b0d7eef4aa3440bfdff3c5a1cadd, < 655d55c5740d37ffdf6233ff5fe21cea879407f1	Fixed in 655d55c5740d37ffdf6233ff5fe21cea879407f1
LinuxLinux	Affected ≥ 591fc34e1f98b0d7eef4aa3440bfdff3c5a1cadd, < 7e4ab3907f44dc243d026048d7f5d477dae9267b	Fixed in 7e4ab3907f44dc243d026048d7f5d477dae9267b
LinuxLinux	Affected =6.4	Fixed in–

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().

References

Community reviews

Loading reviews…