CVE-2026-89601

What it actually does

On ext2, inode metadata updates performed by ext2_setsize() (truncate) and ext2_xattr_set2() (extended attributes) can be silently dropped for IS_SYNC/S_SYNC inodes. The old path called sync_inode_metadata() without first marking the inode dirty; that helper only writes an inode that is already dirty, so in-memory changes to size, xattr block pointers, timestamps, and related fields may never reach disk. The result is stale on-disk inodes, filesystem inconsistency, possible residual data after truncate, and non-persistent security xattrs (ACLs, capabilities, LSM labels). This is a metadata-persistence defect, not a memory-corruption primitive.

Why it matters to the business

Hosts that still mount ext2 (legacy volumes, embedded/IoT images, initramfs, some VMs and appliances) can suffer silent integrity failures: truncated files that keep an old size, missing extra attributes, and fsck-required inconsistency after crash or remount. Residual data and lost access-control xattrs can affect confidentiality and authorization on multi-user volumes. CVSS is 8.8, but EPSS is low and stable (~0.0058 over 30 days), the issue is not in CISA KEV, it is not associated with ransomware, exploit maturity is none, and it has been public about 37 days—treat as a standard kernel integrity patch unless ext2 holds untrusted or compliance-sensitive data.

How an attack unfolds

No public exploit, named threat actor, or ransomware campaign is known. An adversary who can write on an ext2 volume (local account or a network-facing service that stores content on ext2) uses or creates files with the synchronous inode flag (S_SYNC, chattr +S, or equivalent). They truncate the file or set/remove extended attributes. Because the inode is not marked dirty before the sync path, the intended metadata is not flushed. After cache reclaim, crash, or remount, the on-disk inode still has the old size or xattrs. Stale size can expose previously truncated contents; missing POSIX ACL, capability, or LSM xattrs can weaken access control. Impact is integrity-first, with secondary confidentiality and authorization effects—not remote code execution.

How to fix it

Apply the upstream Linux kernel fix that unconditionally mark_inode_dirty() and then call sync_inode_metadata() in both ext2_setsize() and ext2_xattr_set2(). Install a distribution kernel whose changelog maps to CVE-2026-89601; no per-package fixed versions were supplied with this record, so follow vendor/kernel security advisories. If you cannot patch immediately: stop using ext2 for untrusted or multi-user data, prefer ext4 or another maintained filesystem, do not treat chattr +S / S_SYNC as a durability guarantee on unpatched ext2, keep backups, and run fsck.ext2 after unclean shutdowns.

How to confirm the fix worked

Inventory mounts of type ext2 (findmnt -t ext2, fstab, container/VM disk images). Confirm the running kernel includes the CVE-2026-89601 fix via distro advisory mapping or by verifying both ext2_setsize and ext2_xattr_set2 mark the inode dirty before sync_inode_metadata. On a test ext2 filesystem, create a file, set the sync flag, truncate and modify xattrs, remount or drop caches, and verify size and xattrs persist. After production patching, spot-check S_SYNC files and review fsck results on ext2 volumes.

Typical attack path

1. Obtain write access to an ext2-mounted volume (local user or application writing untrusted files).
2. Identify or create files with the synchronous inode flag (S_SYNC / chattr +S).
3. Trigger truncation (ftruncate/truncate → ext2_setsize) or xattr set/remove (setxattr/removexattr → ext2_xattr_set2) on those inodes.
4. Rely on the unsynced, non-dirty inode so the new metadata is never written.
5. After remount, crash, or cache drop, abuse stale file size (residual data) or missing security xattrs.

How to detect it

There is no known in-the-wild exploit, payload, or actor-specific artifact. Hunt for effects of lost metadata rather than a distinctive implant: kernel logs (dmesg, journalctl -k, /var/log/kern.log) for EXT2-fs errors and inode/block bitmap complaints; fsck.ext2 output citing incorrect inode size, orphaned blocks, or xattr errors after crashes or remounts; user-space mismatch between expected and on-disk size or missing ACLs/LSM xattrs on files that have the sync flag; and unusual truncate or setxattr activity by low-privilege users on ext2 mounts. Correlate with unclean shutdowns. Absence of these signs does not prove the bug was never triggered, because lost updates can be silent until remount.

What your security team should do

• Inventory every system that still mounts ext2 and prioritize kernel updates there.
• Deploy vendor/distro kernels that include the CVE-2026-89601 ext2 dirty-then-sync fix.
• Until patched, keep untrusted, multi-tenant, and LSM/ACL-labeled data off ext2 and do not rely on S_SYNC for durability.
• Watch fsck.ext2 reports and ext2 kernel errors for size/xattr inconsistency after crashes.
• Given low stable EPSS, no KEV listing, and no known exploits, use the normal kernel patch cycle unless ext2 is on a high-integrity path.