CVE-2026-31448

What it actually does

This flaw is in the Linux kernel ext4 filesystem extent-handling path used during directory and special-file creation operations such as mkdir and mknod. Under specific failure conditions while mapping logical blocks to physical blocks, ext4 can free a physical block but leave stale extent-tree metadata pointing to it. A later operation can then reuse that stale mapping while the block is also used for extended attributes, causing inconsistent in-memory metadata and an infinite loop in ext4_xattr_block_set(). The practical result is kernel-level blocking while holding inode locks, which can stall filesystem operations and degrade or deny service. Because the bug involves corrupted or inconsistent filesystem metadata, there is also potential for integrity impact to ext4 metadata and files stored on the affected filesystem.

Why it matters to the business

Successful exploitation can make systems using affected Linux kernels and ext4 filesystems hang or become partially unavailable, especially workloads that frequently create directories, device nodes, or files with extended attributes. Operationally, this can interrupt applications, storage services, build systems, container hosts, and servers that rely on ext4-backed storage. Although this issue is not currently listed in CISA KEV, has no reported ransomware use, and has a low EPSS score with no 30-day increase, its high CVSS rating means organizations should treat it as important for Linux fleets where untrusted users, containers, or network-facing services can trigger filesystem writes.

How an attack unfolds

An attacker needs a path to trigger filesystem object creation on an affected Linux system using ext4. This may be direct local access, a container or sandbox that can write to an ext4-backed filesystem, or an exposed service that performs attacker-influenced filesystem operations. The attacker induces repeated mkdir, mknod, or similar metadata-changing operations in a state where ext4 extent insertion fails in a non-ENOSPC/non-EDQUOT way, leaving stale extent metadata that references a reclaimed block. Subsequent operations can cause the directory data and extended-attribute data to contend for the same buffer head. The kernel then loops in ext4_xattr_block_set() while holding inode locks, causing tasks to block for extended periods and potentially making the host or affected mount point unusable until recovery, remount, or reboot.

How to fix it

Upgrade affected Linux kernels to a vendor-supported kernel build that includes the ext4 fix for CVE-2026-31448. No exact upstream or distribution-specific fixed versions were provided in the input, so use the fixed kernel versions published by the relevant Linux distribution, appliance vendor, cloud image provider, or embedded platform maintainer. Prioritize systems using ext4 for writable application data, container storage, shared hosting, CI/build workloads, mail spools, package repositories, or other high-churn filesystem workloads. If immediate patching is not possible, reduce exposure by limiting untrusted local shell access, restricting container write access to ext4-backed host paths, disabling or tightly controlling services that allow unauthenticated or low-privilege users to create arbitrary filesystem objects, applying quotas and resource controls, and monitoring for blocked kernel tasks. Avoid manual filesystem metadata repair unless directed by vendor guidance; use fsck and recovery procedures appropriate for ext4 and the specific distribution.

How to confirm the fix worked

Confirm exposure by inventorying Linux systems running ext4 filesystems and comparing their kernel package versions against vendor advisories for this CVE. Validate remediation by confirming the running kernel after reboot is the patched vendor build, not only that the package is installed. Check mounted filesystems with findmnt -t ext4 or equivalent tooling, and verify kernel version with uname -a and package-manager metadata. Where feasible, run vendor regression tests or non-destructive filesystem workload tests that exercise directory creation and extended attributes on a patched test system. Review kernel logs after patching for absence of repeated blocked-task reports involving ext4_xattr_block_set(), inode_lock_nested(), __start_dirop(), start_dirop(), mkdir, or mknod paths.

Typical attack path

1. Identify or obtain write access to a Linux system using an affected kernel with an ext4 filesystem.
2. Trigger filesystem metadata operations such as mkdir, mknod, or creation of files/directories with extended attributes.
3. Cause or take advantage of an ext4 extent insertion failure that leaves stale extent-tree data referencing a freed physical block.
4. Repeat directory or metadata creation operations so ext4 reuses the stale block reference while the block is also associated with extended attributes.
5. Force the kernel into an infinite loop or prolonged block in ext4_xattr_block_set() while inode locks are held.
6. Degrade filesystem availability, stall dependent services, or force administrative recovery such as remounting, failover, or rebooting.

How to detect it

To determine whether exploitation or triggering has already occurred, review kernel logs, journald, dmesg output, crash dumps, and monitoring alerts for blocked-task warnings, ext4 call traces, and hangs during directory or special-file creation. Useful log sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k, persistent pstore logs, kdump/vmcore analysis, and hypervisor or cloud serial-console logs. Look for tasks blocked for long periods with stack traces including ext4_xattr_block_set(), inode_lock_nested(), __start_dirop(), start_dirop(), or ext4_ext_map_blocks(). Correlate these events with spikes in mkdir, mknod, file creation, container activity, package installation, archive extraction, or services that create extended attributes. Also check for ext4 filesystem errors, remount-read-only events, unexpected application stalls, watchdog resets, node reboots, or storage latency spikes around the same time. There are no public threat actors or campaigns tied to this CVE in the provided data, so detection should focus on behavioral and kernel-artifact evidence rather than actor-specific infrastructure.

• blocked for more than 143 seconds
• ext4_xattr_block_set
• ext4_ext_map_blocks
• inode_lock_nested
• __start_dirop
• start_dirop
• EXT4_GET_BLOCKS_DELALLOC_RESERVE
• task syz.0.17:5995 blocked
• INFO: task
• fs/namei.c:2923
• fs/namei.c:2934
• include/linux/fs.h:1073
• mkdir
• mknod

What your security team should do

• Inventory Linux systems using ext4 and map them to their running kernel versions and distribution support channels.
• Prioritize patching internet-facing, multi-user, container-hosting, CI/CD, shared hosting, and storage-heavy Linux systems first.
• Apply the vendor kernel update that includes the ext4 fix, then reboot or live-patch only if the vendor explicitly supports live-patching this filesystem change.
• Restrict untrusted users and workloads from creating arbitrary files, directories, device nodes, or extended attributes on ext4-backed paths until remediation is complete.
• Monitor kernel logs and SIEM telemetry for blocked tasks, ext4 stack traces, and repeated hangs involving ext4_xattr_block_set() or inode locks.
• Ensure recent backups and filesystem recovery procedures are available for critical ext4 volumes before patch rollout.
• Track vendor advisories for exact fixed package versions because no fixed versions were supplied in the CVE metadata.