CVE-2026-45899

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel ext4 filesystem. When an ext4 extent split operation fails, the kernel may leave stale entries in the extent status tree instead of discarding them. Subsequent filesystem operations can act on inconsistent cached extent state, potentially triggering filesystem errors, kernel warnings, hangs, or a kernel crash/panic. The vulnerability requires local code execution privileges on a system using ext4 and does not provide confidentiality or integrity impact by itself.

Why it matters to the business

A local user or compromised low-privileged process could disrupt systems that use ext4, causing workload interruption, node instability, or unplanned reboot. The risk is most relevant for multi-user Linux systems, shared compute platforms, container hosts, CI/build workers, and any service where untrusted or semi-trusted users can perform filesystem-heavy operations. Public exploit activity is not currently indicated, EPSS is low, and the issue is not in the CISA KEV catalog, but availability-sensitive systems should still prioritize kernel updates during normal maintenance windows.

How an attack unfolds

An attacker first obtains the ability to run code as an unprivileged local user on a Linux system backed by ext4. They then perform filesystem operations that exercise ext4 extent splitting, such as writes, truncates, fallocate/punch-hole operations, or fragmented file manipulations under conditions that cause the split operation to fail. If the failure path leaves stale extent-status entries behind, later ext4 operations may consume inconsistent extent cache data. The result can be filesystem instability or kernel-level failure, leading to denial of service for applications or the host. There is no indication from the supplied data that exploitation is remote, unauthenticated, or currently weaponized in the wild.

How to fix it

Apply a Linux kernel update from the operating system or kernel vendor that includes the ext4 fix to drop potentially stale extents when extent splitting fails. Because no exact fixed versions were provided, track the advisory and patched kernel packages for the relevant distribution or upstream stable kernel branch. After installing the patched kernel, reboot into the updated kernel and verify the running kernel version, not only the installed package version. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted users and workloads, isolating multi-tenant workloads, enforcing disk quotas, monitoring filesystem stress activity, and avoiding untrusted code execution on ext4-backed shared hosts.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the vendor fix for the ext4 extent-split failure path. Check the active kernel with standard host tooling such as `uname -a`, package manager query commands, and vendor advisory metadata. Ensure systems have been rebooted after the kernel update. Validate exposure by identifying systems that use ext4 mounts with `findmnt -t ext4`, `/proc/mounts`, or equivalent inventory tooling. For regression validation in a controlled environment, run filesystem stress tests against ext4 and confirm there are no ext4 extent-cache errors, kernel oopses, panics, or unexpected filesystem remounts. Do not run destructive filesystem stress tests on production systems.

Typical attack path

1. Gain local code execution or shell access as a low-privileged user on a Linux system using ext4.
2. Identify writable ext4-backed storage such as a home directory, temporary directory, container writable layer, or application workspace.
3. Generate filesystem activity that stresses ext4 extent splitting and failure handling, potentially using large, sparse, fragmented, truncated, or fallocated files.
4. Trigger the vulnerable failure path that leaves stale extent-status entries in the kernel extent cache.
5. Continue filesystem operations until the stale state causes ext4 errors, kernel warnings, hangs, or a crash/panic.
6. Cause service interruption, host reboot, or degraded availability.

How to detect it

To assess possible prior exploitation, review kernel and system logs for ext4-related errors, kernel oopses, panics, hangs, or unexpected reboots on systems using ext4. Relevant sources include `dmesg`, journald, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dump tooling such as kdump/vmcore records, EDR telemetry, and uptime/reboot history. Correlate any ext4 failure events with local user activity, suspicious filesystem stress tools, unusual creation or manipulation of sparse/fragmented files, heavy `fallocate`, truncate, punch-hole, or write workloads, and activity in world-writable or shared directories. Because the vulnerability is a kernel logic flaw rather than a malware behavior, there may be no durable file or network artifact; absence of logs does not prove non-exploitation if kernel logs rotated or the host crashed before logs were persisted.

What your security team should do

• Inventory Linux systems using ext4, especially multi-user servers, container hosts, CI runners, shared development systems, and availability-critical workloads.
• Prioritize vendor kernel updates for ext4-using systems, with higher urgency for hosts where untrusted or semi-trusted users can write to local filesystems.
• Reboot systems after patching and verify the active running kernel is the patched version.
• Restrict local access and untrusted workload execution on unpatched ext4 systems until updates are applied.
• Review kernel logs for ext4 errors, kernel oopses, filesystem remounts, or unexplained crashes that coincide with local filesystem-heavy activity.
• Maintain host-level monitoring for abnormal file creation, truncation, fallocate, and disk-stress behavior by low-privileged users on shared systems.
• Ensure backups and recovery procedures are current for systems where filesystem instability could cause operational disruption.