CVE-2026-45948

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel ext4 filesystem implementation. In ext4_ext_shift_extents(), an error path can return immediately when an expected extent is NULL without releasing the extent path allocated by ext4_find_extent(). Repeatedly triggering this path can leak kernel memory. Because the leak occurs in kernel space, sustained exploitation may exhaust available memory and degrade or crash the system. The CVSS vector indicates local access with low attack complexity, low privileges, no user interaction, no confidentiality or integrity impact, and high availability impact.

Why it matters to the business

Systems using affected Linux kernels with ext4 filesystems may be vulnerable to local resource-exhaustion attacks by users, compromised services, containers, or workloads that can exercise the affected filesystem operation. Successful exploitation can cause service instability, degraded performance, out-of-memory conditions, workload termination, or host crashes. This issue is not currently listed in CISA KEV, has very low EPSS, and has no reported public exploit maturity, so urgency is lower than internet-exposed remote-code-execution flaws; however, multi-user systems, shared hosting, CI/CD runners, container hosts, and environments allowing untrusted local code should still prioritize patching.

How an attack unfolds

An attacker first needs local code execution or access to run filesystem operations against an ext4-backed file they can manipulate. They then repeatedly trigger an ext4 extent-shifting code path, such as operations that insert or collapse file ranges, under conditions that cause ext4_ext_shift_extents() to encounter a NULL extent. On vulnerable kernels, that error path returns before freeing the path structure obtained from ext4_find_extent(), leaking kernel memory each time. By looping this operation, the attacker gradually consumes unreclaimable kernel memory until the system experiences memory pressure, the OOM killer terminates processes, services become unstable, or the host crashes or requires reboot.

How to fix it

Upgrade affected Linux kernels to a vendor release that includes the upstream ext4 fix ensuring ext4_ext_shift_extents() jumps to the common cleanup path and releases the extent path before returning. Because no exact fixed package versions were provided, use the applicable distribution or appliance vendor advisories for package-specific kernel versions. After installing the fixed kernel, reboot into the patched kernel; 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, enforcing container isolation, limiting write access to ext4 filesystems, monitoring memory pressure, and applying resource controls such as cgroups, ulimits, and workload memory limits. Consider using maintenance windows to patch shared compute, multi-tenant, and container-hosting systems first.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, is updated to a vendor build containing the ext4 memory-leak fix. Validate with `uname -r`, distribution package metadata, and vendor advisory references. Review whether affected systems use ext4 by checking mounted filesystems with tools such as `findmnt -t ext4` or `/proc/mounts`. If source or build provenance is available, verify that the ext4_ext_shift_extents() error path releases the path via the common cleanup label rather than returning directly when the extent is NULL. After remediation, reboot and confirm the patched kernel is active. Operationally, monitor for absence of recurring memory growth, OOM killer events, and unexplained ext4-related workload instability under representative filesystem workloads.

Typical attack path

1. Gain local execution through a shell, compromised service account, container workload, batch job, or other low-privileged foothold.
2. Identify or create a writable file on an ext4-backed filesystem.
3. Invoke filesystem operations that exercise ext4 extent shifting, such as file range insertion or collapse behavior, under conditions that trigger the NULL extent error path.
4. Repeat the operation many times to accumulate leaked kernel memory.
5. Cause system-wide memory pressure, OOM killer activity, service disruption, or host instability.

How to detect it

To assess possible prior exploitation, focus on host telemetry rather than network logs because exploitation is local. Review kernel logs, system journals, audit logs, EDR process telemetry, and container/runtime logs for repeated memory pressure, OOM killer activity, host instability, or crashes on systems using ext4. Correlate OOM events with local users, containers, or processes repeatedly invoking file range manipulation operations such as fallocate insert-range or collapse-range activity against ext4 files. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, auditd syscall logs if enabled, eBPF/EDR telemetry, container runtime logs, and monitoring metrics for slab/kernel memory growth. There are no known public exploit-specific filenames, command lines, network signatures, or actor-specific indicators from the provided intelligence, so detection should emphasize behavioral correlation: repeated ext4 file manipulation followed by unreclaimed kernel memory growth and OOM conditions.

• Out of memory: Killed process
• oom-killer
• invoked oom-killer
• Memory cgroup out of memory
• Kernel panic - not syncing: Out of memory
• ext4_ext_shift_extents
• ext4_find_extent
• FALLOC_FL_COLLAPSE_RANGE
• FALLOC_FL_INSERT_RANGE

What your security team should do

• Inventory Linux systems using ext4 filesystems, especially shared compute, multi-user hosts, CI/CD runners, container hosts, and systems that run untrusted or semi-trusted local workloads.
• Map each affected system to its running kernel version and the relevant distribution/vendor advisory for the ext4 fix.
• Prioritize patching and rebooting systems where low-privileged users or workloads can write to ext4-backed storage.
• Until patching is complete, restrict local access, reduce untrusted workload execution, and apply cgroup or service-level memory limits to reduce denial-of-service blast radius.
• Add monitoring for sustained kernel memory growth, OOM killer activity, unexpected service restarts, and host-level memory pressure on ext4-backed systems.
• Review logs from the period since publication for unexplained OOM events or memory exhaustion that coincide with heavy file-range manipulation workloads.
• Because KEV status is false, EPSS is very low, and exploit maturity is listed as none, handle as a reliability and local-abuse risk rather than an active mass-exploitation emergency unless local threat exposure is high.