CVE-2026-31449

What it actually does

This is a Linux kernel ext4 filesystem memory-safety flaw in the extent tree repair/update path. When ext4_ext_correct_indexes() walks extent-tree indexes, it can trust a corrupted or crafted on-disk ext4 extent header value and dereference path[k].p_idx outside the valid index-entry range. That results in a slab out-of-bounds read in kernel memory. In practical terms, processing a malicious ext4 filesystem image can trigger kernel memory disclosure, kernel crash/panic, denial of service, and potentially provide a primitive useful in a broader local kernel exploitation chain. The flaw requires local interaction with a malicious or corrupted ext4 filesystem, such as mounting or otherwise causing the kernel ext4 driver to process the crafted metadata.

Why it matters to the business

Systems that mount untrusted disks, removable media, VM images, backup images, forensic images, container/CI artifacts, or other ext4-formatted filesystems are most exposed. Successful exploitation can disrupt workloads through kernel crashes and may expose sensitive kernel memory or help an attacker escalate impact when chained with other bugs. EPSS is currently very low and there is no known CISA KEV listing or public exploit maturity, so broad internet-scale exploitation is unlikely; however, the operational risk is higher for environments that routinely ingest or mount untrusted filesystem images.

How an attack unfolds

An attacker prepares an ext4 filesystem with malformed extent-tree metadata, specifically corrupting extent header/index information so that ext4_ext_correct_indexes() calculates or follows an index pointer beyond the valid entries for that tree level. The attacker then needs the target system to process the malicious filesystem locally, for example by convincing a user or automated workflow to attach and mount a disk image, USB device, virtual disk, backup image, or forensic sample. When the kernel ext4 driver performs extent operations that cause index correction, it reads outside the allocated slab object. Depending on kernel configuration and surrounding memory layout, this may produce a kernel warning, KASAN report, filesystem error, panic, information exposure, or a primitive that could be combined with other vulnerabilities. No named threat actors or active ransomware use are currently reported for this vulnerability.

How to fix it

Upgrade to a Linux kernel version or vendor backport that includes the ext4 fix validating p_idx against EXT_LAST_INDEX() in ext4_ext_correct_indexes() and returning -EFSCORRUPTED for invalid extent indexes. Because no exact fixed package versions were provided, use the relevant distribution security advisory or upstream stable kernel release notes to identify the patched kernel for each supported platform. Until patched, reduce exposure by preventing untrusted users and automated workflows from mounting ext4 filesystems, disabling desktop/server automount of removable media where feasible, processing untrusted disk images only in isolated disposable VMs or sandboxes, restricting loop-device and mount privileges, disabling or tightly controlling unprivileged user namespaces where they enable filesystem mounting paths, and treating corrupted ext4 images as hostile even if fsck can parse them.

How to confirm the fix worked

Confirm the running kernel contains the vendor backport or upstream patch for ext4_ext_correct_indexes() p_idx bounds validation. Validate both the installed kernel package and the currently booted kernel because Linux systems often require a reboot after kernel updates. Check distribution advisories, kernel changelogs, or source/backport metadata for the patch text referencing ext4: validate p_idx bounds in ext4_ext_correct_indexes. Operationally, verify that untrusted ext4 images cannot be mounted by non-approved users or automation, that removable-media automount policies are disabled or controlled, and that test systems processing malformed ext4 images return filesystem-corruption errors rather than KASAN slab-out-of-bounds reports or kernel panics.

Typical attack path

1. Create or modify an ext4 filesystem image with crafted extent-tree metadata, including invalid eh_entries/index bounds.
2. Deliver the malicious filesystem through removable media, a virtual disk, archive, VM image, backup artifact, container/CI artifact, or forensic sample.
3. Cause the target Linux system to mount or otherwise process the ext4 filesystem using the kernel ext4 driver.
4. Trigger extent-tree activity that reaches ext4_ext_correct_indexes(), such as operations involving modified first extents in a leaf.
5. Exploit the out-of-bounds kernel read to crash the system, disclose kernel memory, or support a broader local exploitation chain.

How to detect it

Look for evidence that affected systems mounted or processed untrusted ext4 filesystems shortly before kernel warnings, oopses, crashes, or reboots. Useful sources include dmesg, journald, /var/log/kern.log, /var/log/messages, crash dump infrastructure such as kdump/vmcore, EDR telemetry for mount/losetup/udisks activity, auditd records for mount syscalls, removable-media events, hypervisor or VM-image attachment logs, and CI/backup/forensic automation logs. Search for ext4 corruption reports involving extent trees, KASAN slab-out-of-bounds reads, kernel BUG/Oops traces mentioning ext4_ext_correct_indexes or ext4 extent functions, and mount activity involving recently received disk images or removable media. Because there are no public exploit-specific artifacts, detection should focus on behavioral correlation: unknown ext4 image mounted, followed by ext4 metadata errors or kernel memory-safety diagnostics.

• ext4_ext_correct_indexes
• KASAN: slab-out-of-bounds
• BUG: KASAN: slab-out-of-bounds
• slab-out-of-bounds Read
• EXT4-fs error
• EXT4-fs warning
• EFSCORRUPTED
• ext4_ext_correct_indexes()
• ext4_ext_correct_indexes+
• EXT4-fs error * ext4_ext_correct_indexes
• EXT4-fs error * extent
• kernel BUG at fs/ext4
• Oops:
• Call Trace:
• mount -t ext4
• losetup
• udisksd

What your security team should do

• Prioritize patching Linux systems that mount removable media, VM images, disk images, backup images, forensic samples, CI artifacts, or other externally supplied ext4 filesystems.
• Inventory workflows that automatically attach, scan, mount, or repair ext4 filesystems and isolate them until patched.
• Disable or restrict automount and nonessential loop-device/mount capabilities for untrusted users and services.
• Require suspicious filesystem images to be handled in disposable sandboxed VMs with no access to sensitive networks or credentials.
• Monitor kernel logs for ext4 corruption messages, KASAN slab-out-of-bounds reports, kernel oopses, and panics associated with ext4 extent handling.
• Ensure kernel updates are followed by reboot validation so systems are actually running the patched kernel.
• If crashes or KASAN reports are observed after mounting unknown ext4 media, preserve the filesystem image, kernel logs, and crash dumps for forensic review.