CVE-2026-45858

What it actually does

This is a local Linux kernel ext4 filesystem flaw in extent-splitting logic for unwritten extents. Under specific allocation or end-I/O conversion conditions, ext4 may incorrectly convert a larger extent to written after a failed split caused by temporary metadata-space pressure. This can leave part of the extent in an inconsistent state and may expose stale on-disk data within the filesystem’s block-mapping semantics or cause filesystem integrity issues. The assigned impact is local denial of service with high availability impact: an authenticated local user with the ability to perform filesystem writes on an affected ext4 filesystem may be able to trigger corruption-like behavior, application failures, or filesystem disruption.

Why it matters to the business

Systems using affected Linux kernels with ext4 filesystems may be vulnerable to local disruption by users or workloads that can perform crafted file allocation and write patterns. In multi-user servers, shared hosting, CI/build systems, container hosts, or systems running untrusted local workloads, this can translate into service instability, filesystem errors, downtime, and potential operational recovery work such as remounts, fsck, restore from backup, or kernel maintenance windows. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has very low EPSS, so internet-scale exploitation is unlikely; however, local abuse remains relevant where untrusted users or workloads have write access to ext4-backed storage.

How an attack unfolds

An attacker first needs local authenticated access to a system, container, or workload context that can write to an ext4 filesystem on an affected kernel. They then create file-allocation patterns involving large unwritten extents, such as sparse files or fallocate-style preallocation, and perform writes or I/O completion sequences that force ext4 to split an unwritten extent in the middle. By combining this with conditions that make the first extent split fail temporarily, such as metadata pressure or low available space for extent tree updates, the attacker attempts to drive the vulnerable path in ext4_split_extent() and ext4_split_extent_at(). On vulnerable kernels, ext4 can zero and mark a broader range as written than intended, then later split the extent in a way that leaves a stale or inconsistent written range. The practical result is local filesystem disruption, possible stale-data exposure within affected files, application data inconsistency, or availability loss requiring administrative recovery.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the ext4 fix for this issue. No exact fixed package versions were provided in the input, so use the affected distribution’s security advisory or kernel changelog and deploy the first kernel version containing the upstream ext4 change that avoids converting the entire extent to written when EXT4_EXT_DATA_PARTIAL_VALID1 applies. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads from writing to ext4-backed storage, enforcing quotas to reduce metadata exhaustion scenarios, isolating untrusted containers or users onto separate filesystems, monitoring free space and inode/metadata pressure, and considering temporary use of alternative storage backends for untrusted write-heavy workloads.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed kernel package, is a vendor-patched version containing the ext4 fix. Check the active kernel with uname -r and compare it against the distribution’s security advisory or package changelog. For source-built kernels, confirm the ext4 patch is present in the filesystem/ext4 extent-splitting code and that ext4_split_extent_at() is called with the corrected partial-valid handling for the affected path. Validate exposure by identifying systems that both run affected kernels and mount ext4 filesystems, for example by reviewing /proc/filesystems, findmnt, mount output, or fleet inventory. After patching, perform controlled regression testing on non-production systems using ext4 workloads involving fallocate, sparse files, low-space conditions, and writeback/end-I/O conversion, and verify there are no filesystem errors in kernel logs.

Typical attack path

1. Obtain local authenticated access to a Linux system or workload with write permissions on an ext4 filesystem.
2. Identify or create an ext4-backed writable location where sparse files, unwritten extents, or preallocated files can be manipulated.
3. Create large unwritten extents using file preallocation or sparse-file techniques.
4. Trigger writes or end-I/O conversion paths that require ext4 to split an unwritten extent in the middle.
5. Create temporary metadata-space pressure or similar conditions that can cause the first extent split to fail.
6. Repeat the allocation and write sequence to hit the vulnerable ext4 extent-splitting path.
7. Cause filesystem inconsistency, stale written extents, application errors, or local service disruption.

How to detect it

There are no known public exploit indicators, no KEV listing, no ransomware association, and no unique network telemetry for this local filesystem vulnerability. Detection should focus on signs that the vulnerable ext4 path may have been exercised: kernel logs, journald, dmesg, audit logs, EDR process telemetry, and filesystem health data. Look for unusual local processes repeatedly creating large sparse or preallocated files, heavy fallocate/truncate/write workloads, rapid filesystem space exhaustion and recovery, and ext4 warnings or errors around the same time. Review /var/log/kern.log, /var/log/messages, journalctl -k, dmesg captures, auditd file-operation logs where enabled, and application logs for unexplained I/O errors or data inconsistency. Investigate any ext4 filesystem remounted read-only, aborted journal events, repeated ENOSPC conditions despite available data blocks, or filesystem repairs after crashes. Because exploitation does not require inbound network traffic and may leave no distinctive artifact, absence of logs does not prove absence of exploitation; correlate local user activity and workload behavior with filesystem anomalies.

What your security team should do

• Prioritize patching Linux systems where untrusted local users, CI jobs, containers, shared hosting users, or third-party workloads can write to ext4 filesystems.
• Inventory ext4 usage across Linux fleets and distinguish internet-facing systems with only remote services from systems that also allow local or workload-level write access by untrusted principals.
• Deploy vendor-patched kernels and reboot systems into the fixed kernel; track systems that have installed but not yet booted the update.
• Apply temporary compensating controls on unpatched systems: restrict local access, enforce disk quotas, limit fallocate or large sparse-file abuse where feasible, and isolate untrusted workloads from shared ext4 storage.
• Monitor kernel and filesystem logs for ext4 errors, unexpected remounts read-only, I/O failures, repeated low-space conditions, and application-level data corruption symptoms.
• Because EPSS is very low, there is no KEV listing, and no public exploit maturity is reported, handle this as a local hardening and reliability issue rather than an emergency internet-exposed remote-code-execution event.
• Review backup and restore readiness for critical ext4-backed systems in case filesystem repair or recovery is required.