PatchSiren

PatchSiren cyber security CVE debrief

CVE-2026-45858 Linux CVE debrief

A logic error in the Linux kernel's ext4 filesystem can expose stale data when splitting unwritten extents. When ext4_split_extent() fails to split an extent at point B due to temporary space constraints, it incorrectly marks the entire extent as written after zeroing, leaving stale data in the range 0 to A. A subsequent successful split at A then preserves this stale data as a written extent. The fix passes EXT4_EXT_DATA_PARTIAL_VALID1 during the first split attempt, preventing premature conversion to written status and ensuring proper unwritten extent handling across both split operations.

Vendor
Linux
Product
Unknown
CVSS
Unknown
CISA KEV
Not listed in stored evidence
Original CVE published
2026-05-27
Original CVE updated
2026-05-27
Advisory published
2026-05-27
Advisory updated
2026-05-27

Who should care

Linux system administrators, cloud infrastructure operators, container platform maintainers, and organizations running workloads on ext4 filesystems with large file operations or databases that rely on extent-based storage allocation.

Technical summary

The vulnerability exists in fs/ext4/extents.c in the ext4_split_extent() and ext4_split_extent_at() functions. When allocating initialized blocks from large unwritten extents or splitting during end I/O conversion, a two-part split operation can fail at the first split point (B) due to temporary space constraints. The original code passed EXT4_EXT_DATA_ENTIRE_VALID1 with EXT4_EXT_MAY_ZEROOUT, causing the entire extent to be marked as written after zeroing B to N, leaving stale data in 0 to A. When the second split at A succeeds with EXT4_EXT_DATA_VALID2, this stale data remains as a written extent. The fix uses EXT4_EXT_DATA_PARTIAL_VALID1 for the first split, keeping the extent unwritten after zeroing and allowing proper handling in the subsequent split operation.

Defensive priority

high

Recommended defensive actions

  • Apply kernel updates from your Linux distribution that include the referenced stable kernel commits
  • Reboot systems after kernel update to ensure patched code is active
  • Verify kernel version matches or exceeds fixed versions in stable kernel branches
  • Monitor filesystem integrity on ext4 volumes that handle large unwritten extents
  • Review application data handling for sensitive information that may have been at risk from stale data exposure

Evidence notes

CVE published 2026-05-27. Multiple stable kernel commits provided. No CVSS score or severity assigned by NVD at time of disclosure.

Official resources

2026-05-27