CVE-2026-45912

What it actually does

This is a local Linux kernel ext4 filesystem flaw in extent-status caching during extent splitting. When an unwritten extent is split, ext4 may temporarily cache stale or incorrect extent state, such as recording part of the extent as a hole. Later buffered or delayed writes to the affected range can reinsert delayed extents and corrupt ext4 space accounting. The practical impact is availability loss: filesystem errors, kernel warnings, forced remount read-only, process hangs, or a kernel crash/panic may occur depending on kernel configuration and workload. The CVSS vector indicates local access with low complexity and low privileges, no user interaction, and high availability impact, with no direct confidentiality or integrity impact claimed.

Why it matters to the business

A low-privileged local user or workload with write access to an affected ext4 filesystem may be able to disrupt systems that rely on that filesystem. For servers, build hosts, storage nodes, container hosts, and shared Linux systems, exploitation could interrupt applications, make filesystems temporarily unavailable, force emergency maintenance, or cause downtime through kernel or filesystem failure. The EPSS score is currently very low and the issue is not listed in CISA KEV, so broad active exploitation is not indicated, but the operational impact can still be significant on multi-user or untrusted-workload Linux systems using ext4.

How an attack unfolds

An attacker must already have local code execution or an account that can write to files on an affected ext4 filesystem. They create or manipulate a file backed by unwritten extents, then perform direct I/O writes against part of an unwritten extent so that ext4 splits the extent. During the split, affected kernels may incorrectly cache extent information in the extent status tree, leaving stale state such as a hole where an unwritten extent should remain. The attacker then performs subsequent delayed buffered writes to the remaining range, causing conflicting delayed extent insertion and incorrect space accounting. Repeating or carefully timing this sequence may trigger filesystem errors, warnings, read-only remount behavior, hangs, or a kernel crash, resulting in denial of service.

How to fix it

Upgrade the Linux kernel to a vendor release that contains the ext4 fix for this issue. No exact fixed versions were provided in the input, so use the security advisory from the relevant Linux distribution or kernel vendor and confirm that the ext4 change preventing extent caching during extent splitting is included. Prioritize systems where untrusted users, containers, CI jobs, or shared workloads can write to ext4 filesystems. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted write access to ext4-backed paths, enforcing user quotas, isolating untrusted workloads, using separate disposable filesystems for untrusted jobs, and monitoring for ext4 filesystem errors. Mitigations reduce exploitability but do not correct the kernel bug; patching remains the required fix.

How to confirm the fix worked

Confirm exposure by inventorying Linux systems, kernel versions, and ext4 mounts. Validate remediation by checking that the running kernel package is at or above the distribution’s fixed release and that the system has been rebooted into the patched kernel, not merely installed it. Review vendor changelogs or kernel source to confirm the ext4 fix that avoids caching extents while splitting extents is present. After patching, run filesystem-heavy regression tests involving ext4, direct I/O, fallocate/preallocated files, sparse files, and buffered writes, and confirm no new ext4 warnings, space-accounting errors, read-only remounts, or kernel oops events appear in kernel logs. For critical filesystems, consider offline filesystem checks during a maintenance window if prior ext4 errors were observed.

Typical attack path

1. Obtain local execution or low-privileged shell access on a Linux system using an affected kernel and ext4 filesystem.
2. Identify a writable ext4-mounted path with sufficient quota or free space to create test files.
3. Create or extend a file in a way that produces unwritten extents, such as preallocation or sparse-file operations.
4. Perform direct I/O writes to only part of an unwritten extent, causing ext4 to split the extent.
5. Trigger subsequent delayed buffered writes to the remaining range so stale extent status state conflicts with delayed extent accounting.
6. Repeat the sequence until ext4 reports filesystem/accounting errors, remounts the filesystem read-only, stalls affected workloads, or the kernel crashes.

How to detect it

To determine whether exploitation or attempted exploitation has already occurred, review kernel logs and persistent journal data for ext4 filesystem errors, extent-status warnings, space accounting failures, forced read-only remounts, kernel oops messages, or panics around periods of heavy file-write activity. Useful sources include journald, dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd logs, EDR process telemetry, and container runtime logs for workloads that perform direct I/O, fallocate, sparse-file manipulation, or high-volume writes. Focus on local users or workloads repeatedly creating large files, preallocating extents, mixing direct I/O and buffered I/O, and triggering ext4 errors shortly afterward. There are no reliable network indicators because exploitation is local. Absence of these log messages does not prove non-exploitation, because kernel log retention may be limited and a crash may truncate evidence.

• EXT4-fs error
• EXT4-fs warning
• EXT4-fs (
• Remounting filesystem read-only
• remounting filesystem read-only
• ext4_split_extent_at
• ext4_cache_extents
• extent status tree
• space accounting
• delayed extent
• kernel BUG at fs/ext4
• WARNING: CPU:
• Oops:
• Kernel panic
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Identify Linux systems using ext4 filesystems and affected kernel versions; prioritize shared, multi-user, container-hosting, CI/CD, build, and storage systems.
• Patch to the vendor-fixed kernel release and reboot to ensure the fixed kernel is active.
• Apply temporary controls until patching is complete: restrict local access, limit untrusted write access, enforce quotas, and isolate untrusted workloads from critical ext4 filesystems.
• Search kernel and system logs for ext4 errors, read-only remounts, kernel oops/panic events, and suspicious repeated file preallocation/direct-I/O activity from untrusted users.
• If ext4 errors or remounts occurred, preserve logs and relevant forensic artifacts, assess filesystem health, and consider integrity checks or fsck during approved maintenance.
• Track vendor advisories because exact fixed kernel versions vary by distribution and were not provided in the source data.