CVE-2026-31452

What it actually does

A local user with write access to a file on an affected ext4 filesystem can cause an inode using ext4 inline data storage to become inconsistent by growing the file beyond the inline-data capacity with truncate or a related setattr operation. Subsequent write paths such as sendfile can reach ext4_write_inline_data() while the inode still has the inline-data flag set, triggering a kernel BUG_ON because the requested write size exceeds the inline storage capacity. The primary practical impact is a local kernel crash and denial of service; depending on kernel configuration and surrounding conditions, a kernel bug in filesystem state handling may also present broader integrity or confidentiality risk, which is reflected in the CVSS vector.

Why it matters to the business

Systems using affected Linux kernels with ext4 filesystems may be vulnerable to local denial of service by authenticated users or compromised low-privilege processes. Successful exploitation can crash the kernel, interrupt workloads, force reboots, cause service downtime, and potentially require filesystem checks or recovery if crashes occur during active I/O. The vulnerability is not known to be in CISA KEV, is not reported as used in ransomware campaigns, has no public exploit maturity reported, and has a very low EPSS score, so broad internet-scale exploitation is unlikely; however, multi-user servers, shared hosting, developer workstations, CI runners, container hosts, and systems that allow untrusted local code execution should still treat it as important.

How an attack unfolds

An attacker first needs local code execution or an account capable of creating and modifying files on an affected ext4 filesystem. They create or identify a small file stored using ext4 inline data, then expand its apparent size beyond the inline-data capacity using truncate, ftruncate, or an equivalent file size change operation. On vulnerable kernels, the inode can retain the inline-data flag even though the file size no longer fits inline storage. The attacker then triggers a write path such as sendfile that attempts to write data through ext4_write_inline_data(). Because the kernel still believes the file should be handled as inline data, the write size exceeds the inline capacity and a BUG_ON is hit, causing a kernel oops/panic or system crash depending on panic-on-oops settings. There is no indication from the supplied intelligence that this issue is being actively exploited by named threat actors.

How to fix it

Apply the vendor kernel update that includes the ext4 fix converting inline-data files to extent-based storage when a truncate or setattr operation grows the file beyond inline capacity. No exact fixed package versions were provided in the input, so use the fixed kernel versions published by the relevant Linux distribution or kernel vendor for CVE-2026-31452. Reboot systems after installing the updated kernel to ensure the running kernel is patched. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, isolating containers and CI jobs, enforcing least privilege, and avoiding use of ext4 inline data where feasible. Operational mitigations are partial only; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel version, not only the installed package version, has the ext4 fix applied. Validate with distribution advisory tooling, package changelogs, or kernel source/backport notes referencing the ext4 inline-data truncate-to-extents fix. After patching and rebooting, verify that the active kernel is the updated one with uname and package manager metadata. On representative non-production systems, a controlled regression test can create an inline-data ext4 file, grow it beyond inline capacity with truncate, then exercise a write path such as sendfile; a fixed kernel should convert the file to extent-based storage and must not oops or panic. Also review kernel logs after validation for absence of ext4_write_inline_data BUG or related ext4 inline-data assertions.

Typical attack path

1. Obtain local access to a Linux system running an affected kernel and using an ext4 filesystem.
2. Create or locate a small ext4 file that is stored with inline data.
3. Use truncate, ftruncate, or a similar setattr operation to grow the file far beyond the ext4 inline-data capacity.
4. Trigger a subsequent write operation, commonly through sendfile or another kernel write path.
5. Cause ext4_write_inline_data() to encounter an impossible inline write size and hit a kernel BUG_ON.
6. Crash the kernel or destabilize the host, resulting in denial of service.

How to detect it

Look for evidence of kernel instability or crashes involving ext4 inline data handling. Primary sources include journald, syslog, dmesg output, /var/log/kern.log, /var/log/messages, pstore, kdump/vmcore artifacts, and crash dump analysis. Search for kernel oops, BUG, panic, or call traces mentioning ext4_write_inline_data, ext4 inline data, ext4_setattr, truncate/ftruncate, or sendfile shortly before a reboot or service outage. If auditd or eBPF syscall telemetry is available, look for suspicious sequences from the same user or process that create small files on ext4, grow them dramatically with truncate or ftruncate, and then invoke sendfile or heavy write operations. Because this issue primarily manifests as a local kernel crash, durable artifacts may be limited unless persistent kernel logging, pstore, or crash dumping was enabled before the event.

• BUG: kernel BUG at fs/ext4/inline.c
• kernel BUG at fs/ext4/inline.c
• ext4_write_inline_data
• BUG_ON(write_size > inline_capacity)
• Call Trace:
• ext4_setattr
• EXT4-fs
• inline data
• sendfile
• truncate
• ftruncate
• /var/log/kern.log
• /var/log/messages
• /sys/fs/pstore/
• /var/crash/
• vmcore

What your security team should do

• Prioritize patching affected Linux systems that permit local user access, run untrusted code, host containers, run CI/CD workloads, or support shared application environments.
• Track distribution advisories for the exact fixed kernel packages and ensure systems are rebooted into the patched kernel.
• Harden local access paths by reducing unnecessary shell access, enforcing least privilege, and isolating untrusted workloads until patching is complete.
• Monitor kernel logs for ext4 BUG, oops, panic, or stack traces involving ext4_write_inline_data, truncate, and sendfile.
• For high-availability services, schedule kernel updates with reboot planning to avoid unplanned outage from either exploitation or patch deployment.
• If crash indicators are found, preserve kernel logs, crash dumps, audit logs, and recent file-operation telemetry before reboot cleanup overwrites evidence.