CVE-2026-89772: 
Linux Kernel vulnerability analysis and mitigation

CVE-2026-89772 is a data integrity vulnerability in the Linux kernel's btrfs filesystem subsystem, caused by improper resource locking (CWE-413) during data writeback. The flaw was introduced by commit a4ef54dbb576 ("btrfs: make extent_range_clear_dirty_for_io() to handle sector size < page size cases"), which removed the folio_clear_dirty_for_io() call in extent_write_cache_pages(), eliminating write-protection of shared mmap PTEs during writeback. Affected versions include Linux kernel 6.13 up to (but not including) the fix commits; versions prior to 6.13 and 7.2.4+ are unaffected. The vulnerability was published on September 11, 2026, with patches available in the stable kernel tree. The CVSS category is estimated as HIGH (Red Hat Advisory, Github Advisory).

The root cause is classified as CWE-413 (Improper Resource Locking). The folio_clear_dirty_for_io() function previously served a dual purpose: clearing the dirty flag and calling folio_mkclean() to write-protect shared mmap PTEs. When commit 095be159f3eb replaced this call with a plain folio_test_dirty() check in extent_write_cache_pages(), the write-protection step was lost. A local process with an existing mmap-ed PTE can then write to a folio without triggering a page fault while the kernel is concurrently performing writeback operations (checksumming, compressing, copying). This race condition affects multiple code paths: large folios or subpage sectorsize bio submissions, zoned writes spanning two folios, inline extent copying, compressed extent processing in run_delalloc_compressed(), and folios spanning EOF. The attack vector is local, requiring the attacker to have mmap access to a file on a btrfs filesystem (Github Advisory, Red Hat Advisory).

Successful exploitation allows a local user or process with mmap access to a btrfs-mounted file to corrupt data during disk write operations, with several concrete consequences: invalid checksums leading to corruption reports on subsequent reads, silent loss of writes even after fsync() is called, corrupted compressed data, and improper persistence of zeroed bytes past EOF that future page faults would incorrectly expose. The impact is primarily to data integrity and availability of the btrfs filesystem, with no direct confidentiality breach. Corruption may persist to storage, potentially causing filesystem inconsistencies that are difficult to recover from without backups (Github Advisory, Red Hat Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (Red Hat Advisory). Exploitation requires local access and the ability to mmap a file on a btrfs filesystem, limiting the attack surface to local privilege contexts. No threat actor attribution, EPSS score, or CISA KEV catalog listing has been reported for this vulnerability.

1. Precondition: Obtain local access to a system running Linux kernel 6.13 with a btrfs filesystem mounted.
2. Open and mmap a target file: Open a file on the btrfs filesystem and create a shared mmap mapping using mmap() with MAP_SHARED and PROT_WRITE.
3. Trigger writeback: Initiate a writeback operation on the file (e.g., by calling msync(), fsync(), or by writing enough dirty data to trigger kernel-initiated writeback via pdflush/kworker).
4. Race the writeback window: While the kernel is executing extent_write_cache_pages() and a bio is in flight (but before folio_clear_dirty_for_io() is called on the last sector), write to the mmap-ed region via the existing PTE without triggering a page fault — this is possible because the PTE was not write-protected due to the missing folio_mkclean() call.
5. Achieve data corruption: Depending on timing, the write may corrupt checksums (if it arrives during checksumming), cause silent data loss (if it arrives after checksumming but before dirty bit clearing), or corrupt compressed data (if targeting a compressed extent being processed by compress_file_range()) (Github Advisory).

• Logs: Kernel log messages (dmesg) reporting btrfs checksum verification failures (e.g., BTRFS error: bdev ... errs: wr 0, rd 0, flush 0, corrupt N, gen 0) or read-time corruption errors on a btrfs volume.
• File System: Unexpected data corruption detected by btrfs scrub or btrfs check; files with mismatched checksums reported by btrfs integrity checking tools.
• Process Behavior: Processes with both mmap() and active writeback on btrfs files exhibiting unusual timing patterns; unexpected msync()/fsync() call sequences from user-space processes coinciding with writeback activity.
• Kernel Events: Btrfs-related kernel warnings or BUG traces in /var/log/kern.log or journalctl -k related to folio or extent writeback operations.

Apply Linux kernel updates that include the fix commits restoring folio_clear_dirty_for_io() in extent_write_cache_pages(): stable commit 074c715e0b498891c09fe7f11e1cd9d7a04699bd and 5376c9db45368eb210b4d71104ac00a59dc8b6e0. Kernel versions 7.2.4 and later (including 7.3-rc1) are unaffected. As a temporary workaround where patching is not immediately possible, avoid using large folios or subpage sector sizes on btrfs filesystems, and restrict untrusted local user access to btrfs-mounted filesystems. Monitor systems for btrfs checksum errors using btrfs scrub as a detection measure (Github Advisory, Red Hat Advisory).

The vulnerability received brief coverage in automated CVE aggregation communities, including a mention in a Reddit CVE daily brief on September 12, 2026. No notable independent researcher commentary or vendor statements beyond the Red Hat advisory and kernel mailing list announcement have been identified. Community sentiment appears low-urgency given the absence of a public PoC and the local-only attack vector.