CVE-2026-45892

What it actually does

This Linux kernel ext4 flaw is a local availability issue in extent handling. Under specific buffered-write conditions involving unwritten extents, partial zeroing, and a failed intermediate extent split, ext4 can leave a stale unwritten extent entry in the in-memory extent status tree after the on-disk extent has been converted to written. That inconsistency can lead to incorrect filesystem state handling and kernel/filesystem errors, potentially causing denial of service through filesystem malfunction, forced remount read-only behavior, process I/O failures, or system instability. The CVSS vector indicates local access with low attack complexity and low privileges required, with high availability impact and no direct confidentiality or integrity impact scored.

Why it matters to the business

Systems using affected Linux kernels with ext4 filesystems may experience service disruption if a local user or workload triggers the vulnerable write/extent sequence. The most likely operational impact is outage or degradation from filesystem errors, failed writes, read-only remounts, application crashes, or host instability. Because this is not in CISA KEV, has no reported exploit maturity, and has a very low EPSS score, broad active exploitation is not currently indicated; however, internet-facing status is less relevant because exploitation is local and may be possible from compromised accounts, containers with write access to ext4-backed storage, batch jobs, or multi-user environments.

How an attack unfolds

An attacker first needs the ability to execute code or perform file writes locally on a system using an affected Linux kernel and ext4 filesystem. They then create or manipulate a file with unwritten extents, such as through preallocation or sparse-file behavior, and perform buffered writes into the middle of that range under conditions where ext4 attempts to split and initialize part of an unwritten extent. If the first split operation temporarily fails, ext4 may zero part of the extent while leaving the extent status cache stale. A later split can mark the on-disk range as written while the in-memory extent status tree still contains stale unwritten information. Repeating or carefully timing these operations can trigger filesystem inconsistencies and availability failure modes such as ext4 errors, I/O failures, read-only remounts, or kernel instability. There are no named threat actors or public exploitation maturity reported for this issue in the provided data.

How to fix it

Upgrade to a Linux kernel version that includes the ext4 fix for dropping the cached extent status entry after PARTIAL_VALID1 zeroout. If consuming kernels through a Linux distribution, apply the vendor kernel security/maintenance update rather than attempting to patch ext4 manually. No exact fixed package versions were provided, so verify remediation through the relevant distribution advisory, upstream stable kernel changelog, or kernel package changelog for the ext4 change described as dropping/invalidating the extent cache after partial-valid zeroout. Reboot into the updated kernel after installation; simply installing a kernel package is not sufficient if the host continues running the vulnerable kernel. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads that can write heavily to ext4 filesystems, isolating multi-tenant workloads, enforcing disk quotas and cgroup limits, and monitoring ext4 error activity. Consider using filesystem and host-level resilience controls such as backups, journaling health checks, and automated recovery procedures, but treat these as mitigations rather than fixes.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, has been updated to a build containing the ext4 fix. On Linux systems, compare `uname -r` with the distribution advisory or package changelog, and verify the system has rebooted into the patched kernel. Review vendor release notes or source changelogs for the ext4 fix related to invalidating/dropping extent status cache entries after PARTIAL_VALID1 zeroout in ext4 split extent handling. Validate exposure by identifying systems using ext4 with `findmnt -t ext4`, `/proc/mounts`, or equivalent asset inventory. After patching, run representative file-write and filesystem health tests and confirm there are no recurring ext4 errors in `dmesg`, kernel logs, or journald. For high-value systems, schedule filesystem checks during maintenance windows if prior ext4 errors, read-only remounts, or unexplained I/O failures were observed.

Typical attack path

1. Obtain local code execution or a low-privileged local account on a Linux system using an affected kernel and ext4 filesystem.
2. Identify a writable ext4-backed filesystem, including local disk, VM disk, or ext4-backed application storage.
3. Create or manipulate files with unwritten extents, commonly through sparse-file or preallocation-style operations.
4. Perform buffered writes into the middle of an unwritten extent to force ext4 extent splitting and conversion from unwritten to initialized/written state.
5. Trigger the edge case where one extent split fails after zeroout and a subsequent split succeeds, leaving stale extent-status cache state.
6. Repeat or stress the operation until the filesystem or kernel enters an error condition, causing I/O failures, read-only remount, service disruption, or host instability.

How to detect it

Look for evidence of prior exploitation or triggering through kernel and filesystem telemetry rather than network indicators, because this is a local ext4 kernel issue. Review `dmesg`, journald kernel logs, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, and EDR process/file activity around times of filesystem instability. Key signs include ext4 errors or warnings, filesystem remounted read-only, repeated I/O failures, kernel warnings/oops traces involving ext4 extent handling functions, and sudden service failures caused by inability to write to disk. Correlate these events with local users, containers, jobs, or processes performing unusual sparse-file creation, preallocation, truncation, or high-volume buffered writes on ext4-backed filesystems. Useful commands and APIs to investigate process behavior may include auditd file-write events, eBPF/file integrity telemetry, shell history for file allocation tools, container runtime logs, and workload scheduler logs. There are no public threat actor or campaign indicators provided, and absence of these log strings does not prove non-exploitation if logs were rotated or kernel errors did not surface visibly.

• EXT4-fs error
• EXT4-fs warning
• Remounting filesystem read-only
• ext4_split_extent
• ext4_split_extent_at
• ext4_map_create_blocks
• extent status tree
• Buffer I/O error
• I/O error, dev
• Aborting journal on device
• Journal has aborted
• previous I/O error to superblock detected
• error count since last fsck
• Filesystem has been set read-only

What your security team should do

• Prioritize patching Linux systems that combine affected kernels, ext4 filesystems, and local untrusted or semi-trusted users/workloads, such as shared compute, CI runners, application hosting nodes, container hosts, and VDI/jump systems.
• Inventory ext4 usage across Linux fleets and map it to running kernel versions; focus remediation on running kernels rather than installed packages alone.
• Apply vendor kernel updates and reboot into the fixed kernel; track exceptions where reboot delays leave the vulnerable kernel active.
• Until patched, restrict local interactive access and untrusted write-heavy workloads on ext4-backed storage, and enforce quotas or workload isolation where possible.
• Monitor kernel, journald, syslog, and filesystem health telemetry for ext4 errors, read-only remounts, unexpected I/O failures, or kernel warnings involving ext4 extent functions.
• Investigate any recent ext4-related instability on affected kernels, especially where it coincides with unusual local file allocation, sparse-file, or heavy buffered-write activity.
• Because EPSS is low, not KEV-listed, and exploit maturity is reported as none, handle as a reliability/security maintenance priority rather than an emergency internet-wide exploitation event unless local adversary risk is elevated.