CVE-2026-31451

What it actually does

This flaw is a local denial-of-service issue in the Linux kernel ext4 filesystem code. When ext4_read_inline_folio() encounters a corrupted or crafted ext4 inode whose inline data size exceeds PAGE_SIZE, vulnerable kernels hit a BUG_ON() assertion and panic instead of handling the condition as filesystem corruption. The fix replaces the panic condition with normal error handling: it logs the corruption through ext4_error_inode(), releases the buffer head to avoid a leak, and returns -EFSCORRUPTED so the system can continue operating.

Why it matters to the business

A user or process with local access to a vulnerable Linux system may be able to crash the host by triggering ext4 handling of malformed inline filesystem data. The primary risk is service interruption, workload disruption, and possible unplanned reboot or failover. Risk is lower than remotely exploitable kernel issues because exploitation requires local privileges or the ability to get a crafted ext4 filesystem/image mounted and read, and there is no known public exploitation, KEV listing, or ransomware association. However, systems that process untrusted disk images, removable media, backups, forensic images, or user-supplied filesystem artifacts have higher operational exposure.

How an attack unfolds

An attacker first needs a path to influence ext4 filesystem metadata that will be processed by a vulnerable kernel. This could involve local user access to a system, access to a removable or virtual disk image that an administrator or automated workflow mounts, or control over an ext4 image handled by backup, CI, build, sandboxing, or forensic tooling. The attacker prepares or corrupts an ext4 inode using inline data so that the inline data size exceeds PAGE_SIZE. When the vulnerable kernel reads the affected inline-data inode through ext4_read_inline_folio(), the kernel reaches a BUG_ON() assertion and panics. Successful exploitation causes a denial of service through kernel crash/reboot rather than code execution or data theft.

How to fix it

Update the Linux kernel to a vendor-supported version containing the ext4 fix that replaces the BUG_ON() in ext4_read_inline_folio() with proper filesystem-corruption handling. Because fixed versions vary by distribution and kernel branch, use the security advisories and packages from the relevant OS vendor or kernel maintainer rather than relying on upstream version numbers alone. After updating, reboot into the fixed kernel and remove or restrict boot entries for vulnerable kernels where operationally appropriate. As mitigations until patching is complete, avoid mounting untrusted ext4 filesystems or disk images on production hosts, mount removable or user-supplied media only in isolated environments, restrict loop-device and mount privileges, and use read-only/noexec/nosuid/nodev mount options where applicable. Filesystem integrity checks such as e2fsck may help identify corruption but should not be treated as a complete mitigation for vulnerable kernels.

How to confirm the fix worked

Confirm exposure by checking whether systems run a Linux kernel build that predates the vendor fix for this ext4 issue and whether ext4 is in use or untrusted ext4 images/media are processed. Validate remediation by confirming the running kernel version after reboot, not just the installed package version, using commands such as uname -a and distribution package tooling. Review vendor changelogs or kernel source packages for the ext4_read_inline_folio fix replacing BUG_ON() with ext4_error_inode() and -EFSCORRUPTED handling. Functional validation can include mounting and checking representative ext4 filesystems in a non-production test environment and confirming corrupted inline-data conditions are reported as filesystem errors rather than causing a kernel panic.

Typical attack path

1. Obtain local access to a Linux system or find a workflow that mounts or reads attacker-controlled ext4 filesystems or disk images.
2. Create or modify an ext4 filesystem, image, or block device so an inode with inline data reports an inline data size larger than PAGE_SIZE.
3. Cause the vulnerable system to mount and access the malformed ext4 content.
4. Trigger a read path that calls ext4_read_inline_folio() for the corrupted inline-data inode.
5. Kernel hits the vulnerable BUG_ON() condition and panics, causing system outage or reboot.

How to detect it

Look for evidence of kernel panic, unexpected reboot, or ext4 corruption messages around the time a system mounted or accessed removable media, loop devices, VM/container disk images, backup images, or other untrusted ext4 filesystems. Relevant log sources include the kernel ring buffer, system journal, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump facilities such as kdump/vmcore, hypervisor reset events, EDR telemetry for mount/losetup activity, and audit logs for mount-related syscalls. Search for ext4 inline-data corruption messages, kernel BUG/panic traces referencing ext4_read_inline_folio, and activity involving mount, losetup, qemu-nbd, guestmount, or similar tooling shortly before a reboot. Because this issue causes availability impact rather than persistent compromise, indicators are likely to be crash artifacts and filesystem-processing events rather than malware files or network callbacks.

• ext4_read_inline_folio
• kernel BUG at fs/ext4/inline.c
• BUG_ON
• Kernel panic - not syncing
• EXT4-fs error
• ext4_error_inode
• EFSCORRUPTED
• inline data
• inline_data
• Buffer I/O error on dev loop
• mount -t ext4
• losetup
• qemu-nbd
• guestmount
• /var/crash/
• /proc/vmcore
• vmcore
• kdump

What your security team should do

• Prioritize patching Linux systems that mount or analyze untrusted ext4 media, virtual disks, container/VM images, backup images, or forensic artifacts.
• Update affected systems to vendor-fixed kernels and reboot to ensure the fixed kernel is active.
• Restrict the ability of non-administrative users and automated jobs to mount loopback devices, removable media, or user-supplied ext4 images.
• Review workflows that ingest third-party disk images and move them into isolated sandbox hosts until patching is complete.
• Monitor for kernel panic, ext4 corruption, and unexpected reboot events that may indicate attempted triggering or unstable storage.
• Maintain normal priority patching for general-purpose systems, as EPSS is very low, there is no known exploited-in-the-wild status, and exploitation requires local or filesystem-input access.