CVE-2026-45858: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-45858 Overview

CVE-2026-45858 is a Linux kernel vulnerability in the ext4 filesystem affecting how unwritten extents are split and converted to initialized state. When the kernel allocates initialized blocks from a large unwritten extent, or splits an unwritten extent during end I/O, a failed mid-extent split followed by a successful retry can leave stale data exposed in the resulting written extent. The flaw resides in the ext4_split_extent() and ext4_split_extent_at() code paths. Successful exploitation results in information disclosure from previously allocated disk blocks. The vulnerability has been resolved upstream in the Linux kernel stable tree.

Critical Impact
Stale on-disk data can be exposed to userspace through ext4 extent state transitions, leading to information disclosure of previously written filesystem blocks.

Affected Products

Linux kernel (ext4 filesystem subsystem)
Distributions shipping vulnerable kernel versions prior to the stable fixes referenced in git.kernel.org
Systems using ext4 with large unwritten extents (fallocate workloads, databases, virtualization images)

Discovery Timeline

2026-05-27 - CVE-2026-45858 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-45858

Vulnerability Analysis

The vulnerability stems from incorrect state handling during a two-step unwritten extent split in the ext4 filesystem [Kernel Vulnerability]. Consider an unwritten extent spanning blocks 0 to N with valid data between A and B. The kernel must initialize the range A to B while preserving the unwritten state outside that range.

ext4_split_extent() first attempts to split at position B with the EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flags. If ext4_split_extent_at() fails due to temporary lack of space, the kernel falls back to zeroing out blocks B through N and marking the entire range 0 to N as written. This conversion is incorrect because blocks 0 to A still contain stale on-disk content that was never valid data.

When ext4_split_extent() then splits at A with EXT4_EXT_DATA_VALID2, the operation succeeds but leaves a written extent from 0 to A containing stale data. Userspace reads of that range now return the stale contents instead of zeros.

Root Cause

The root cause is the premature conversion of the entire extent to a written state after a partial zeroout. The original code treated the zeroout as making the whole extent valid, when only the tail portion (B to N) had been zeroed. Blocks before the valid data region (0 to A) were never initialized.

Attack Vector

A local attacker capable of triggering fallocate workloads and concurrent I/O against ext4-backed storage can race the extent split path to surface stale block content. The attack requires no special privileges beyond filesystem access. The exploitation conditions depend on transient ENOSPC behavior in ext4_split_extent_at(), which can be induced under filesystem pressure. The vulnerability manifests during normal direct I/O, AIO, or buffered write completion paths against pre-allocated files.

No public proof-of-concept code is available. The upstream patch description in the kernel commit messages provides the technical detail required to understand the flaw. See the Kernel Git Commit Update 1 for the fix implementation.

Detection Methods for CVE-2026-45858

Indicators of Compromise

Unexpected non-zero content in regions of files created via fallocate() that should read as zero before being written
Filesystem consistency anomalies surfaced by e2fsck against ext4 volumes under heavy unwritten-extent workloads
Kernel log entries from ext4 indicating extent split or zeroout activity correlated with ENOSPC conditions

Detection Strategies

Inventory running kernel versions across the fleet and compare against the fixed stable releases referenced in the upstream commits
Monitor filesystems hosting database files, VM images, and other fallocate-heavy workloads for read patterns that surface unexpected non-zero data
Audit kernel package versions through configuration management tooling to confirm patch deployment

Monitoring Recommendations

Collect kernel version telemetry from all Linux endpoints and servers and centralize it for compliance reporting
Track ext4 error counters and dmesg output for extent-related warnings
Alert on kernels that remain at vulnerable versions beyond the patch window

How to Mitigate CVE-2026-45858

Immediate Actions Required

Apply the upstream stable kernel patches referenced in the kernel.org commit links and reboot affected systems
Prioritize patching of hosts running database, virtualization, and container workloads that make heavy use of fallocate() and unwritten extents
Validate vendor kernel updates from your Linux distribution and deploy them through standard change management

Patch Information

The fix passes EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, avoiding the incorrect conversion of the entire extent to written after zeroing only the tail. The extent remains unwritten outside the valid data range until the second split at A completes, at which point the proper state is set. Patch commits are available at Kernel Commit 1bf6974822d1, Kernel Commit 58ddae5d77b1, Kernel Commit 7015fcf47379, Kernel Commit d17857b4fb9b, and Kernel Commit d67c8ecf3d8f.

Workarounds

No reliable workaround exists short of patching; reducing fallocate-based pre-allocation may lower exposure but does not eliminate the flaw
Consider alternative filesystems such as XFS for workloads that cannot be patched immediately
Maintain filesystem free space headroom to reduce the ENOSPC conditions that trigger the vulnerable fallback path

bash

# Verify the running kernel version and pending updates
uname -r

# Debian/Ubuntu: install the latest kernel and reboot
sudo apt-get update && sudo apt-get install --only-upgrade linux-image-generic
sudo reboot

# RHEL/CentOS/Rocky/Alma: update kernel package and reboot
sudo dnf update kernel
sudo reboot

# Confirm the post-patch kernel version matches a fixed stable release
uname -r