CVE-2026-31450

What it actually does

This is a race condition in the Linux kernel ext4 journaling/fast-commit path. ext4_inode_attach_jinode() could publish an inode journal pointer before the underlying jbd2 inode was fully initialized. A concurrent reader could observe the pointer as valid, pass it into the journaling data-wait path, and dereference an uninitialized i_vfs_inode field. The most directly evidenced impact is a kernel page fault/Oops during ext4 fast-commit or fsync/fdatasync activity, potentially leading to a system crash or denial of service. Because the flaw occurs in kernel memory handling, successful exploitation may also carry broader confidentiality and integrity risk depending on kernel configuration, memory layout, and exploitability conditions, though no public exploit maturity is currently reported.

Why it matters to the business

Systems using affected Linux kernels with ext4 filesystems may be vulnerable to crashes triggered by crafted or high-frequency filesystem synchronization activity. On servers, appliances, container hosts, storage nodes, and embedded devices, this can cause service interruption, forced reboot, workload disruption, and possible data consistency concerns after an unplanned kernel failure. The CVSS score is high, but EPSS is currently low and stable, the issue is not in CISA KEV, and no exploit maturity is reported, so remediation should be prioritized for internet-exposed multi-user systems, shared hosting/container platforms, storage-heavy workloads, and systems where unprivileged users or remote application paths can trigger filesystem writes and fsync/fdatasync operations.

How an attack unfolds

An attacker first needs a way to cause filesystem operations on an affected Linux system, typically through a local low-privileged account, a container workload with access to an ext4-backed writable filesystem, or a remotely reachable service that writes attacker-controlled data and forces synchronization to disk. The attacker then generates concurrent ext4 activity designed to exercise inode attachment, journaling, fast commits, and fsync/fdatasync paths at the same time. If the race is won, one kernel thread observes ei->jinode before initialization has completed. The fast-commit flush path can then call into the jbd2 inode data-wait logic using this partially initialized object, leading to a dereference of an invalid or unset i_vfs_inode mapping and a kernel page fault. In practical terms, the expected outcome is a kernel Oops/panic and service outage; more advanced exploitation would require turning the race and invalid dereference into controlled kernel memory impact, which is not currently known to be publicly demonstrated for this CVE.

How to fix it

Upgrade affected Linux kernels to a version that includes the ext4 fix which initializes the jbd2 inode before publishing ei->jinode, using the memory-ordering changes with smp_wmb(), WRITE_ONCE(), and READ_ONCE(). No exact fixed package versions were provided in the input, so use distribution or vendor kernel advisories for the relevant branch and install the first kernel release that contains the upstream patch titled "ext4: publish jinode after initialization". Reboot systems after installing the updated kernel; live patching should only be considered sufficient if the vendor explicitly states this CVE is covered. Where immediate patching is not possible, reduce exposure by limiting untrusted local shell access, constraining container workloads, avoiding untrusted write-heavy workloads on ext4-backed filesystems, and disabling or isolating services that allow remote users to force frequent disk synchronization. Mitigations should be treated as temporary because this is a kernel race condition and reliable prevention requires the patched kernel code.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking uname -a and distribution package metadata after reboot. Validate vendor advisory coverage for CVE-2026-31450 or for the ext4 patch "ext4: publish jinode after initialization". On source-built kernels, confirm the ext4 code initializes the jbd2 inode before assigning/publishing ei->jinode and uses the intended READ_ONCE()/WRITE_ONCE() access pattern. Review boot and kernel logs after upgrade for absence of new ext4 fast-commit crashes under representative filesystem workloads. If safe in a non-production test environment, reproduce high-concurrency ext4 fsync/fdatasync workloads before and after patching to verify the crash condition no longer occurs. Inventory systems using ext4 filesystems and prioritize those running kernels released before the vendor backport date or upstream fix inclusion.

Typical attack path

1. Obtain the ability to trigger writes and synchronization operations on an affected Linux system using ext4, such as through a local account, containerized workload, or vulnerable application write path.
2. Create or modify files on an ext4-backed filesystem while repeatedly invoking fsync(), fdatasync(), or equivalent application behavior.
3. Run concurrent filesystem activity to increase the chance of overlapping ext4 inode journaling initialization with fast-commit flush handling.
4. Win the race so a reader observes a non-NULL ext4 journal inode pointer before the jbd2 inode is fully initialized.
5. Trigger the ext4 fast-commit path to pass the partially initialized journal inode into jbd2_wait_inode_data().
6. Cause the kernel to dereference an unset or invalid i_vfs_inode->i_mapping pointer, resulting in a page fault, Oops, panic, or system crash.

How to detect it

Look for evidence of kernel crashes or Oops events associated with ext4 fast commit and inode synchronization paths. Primary log sources include journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, kernel crash dumps, pstore/ramoops records, kdump vmcores, hypervisor reset events, and availability monitoring showing unexpected reboots. Focus on stack traces containing ext4_fc_commit, ext4_sync_file, jbd2_wait_inode_data, filemap_get_folios_tag, __filemap_fdatawait_range, xas_find_marked, __x64_sys_fdatasync, do_fsync, or fdatasync/fsync syscall activity shortly before a crash. Also correlate with unusual spikes in file synchronization, write-heavy local user activity, container workloads, upload-processing services, database-like workloads, or benchmark-style filesystem stress tools. There are no known network indicators specific to this flaw; detection is primarily host-based and crash-artifact based. Absence of logs does not prove absence of exploitation if volatile kernel logs were lost during reboot, so verify persistent kernel logging and crash dump retention.

• BUG: unable to handle page fault
• Oops: Oops: 0000
• RIP: 0010:xas_find_marked
• xas_find_marked+0x
• filemap_get_folios_tag+0x
• __filemap_fdatawait_range+0x
• filemap_fdatawait_range_keep_errors+0x
• ext4_fc_commit+0x
• ext4_sync_file+0x
• jbd2_wait_inode_data
• __x64_sys_fdatasync+0x
• do_fsync+0x
• entry_SYSCALL_64_after_hwframe
• CR2: 000000010beb47f4
• Comm: fc_fsync_bench_

What your security team should do

• Prioritize patching Linux systems that provide untrusted local access, run containers or shared workloads, expose upload/write-heavy services, or host critical ext4-backed storage.
• Track distribution advisories and install the first vendor kernel version that explicitly includes the ext4 jinode initialization race fix; reboot to activate it.
• Search kernel logs and centralized telemetry for Oops/panic traces involving ext4_fc_commit, ext4_sync_file, jbd2_wait_inode_data, filemap_get_folios_tag, or xas_find_marked.
• Temporarily restrict untrusted users and workloads from generating high-rate fsync/fdatasync activity on ext4 filesystems until systems are patched.
• Review container and sandbox boundaries because a low-privileged workload may still be able to crash the shared host kernel if it can exercise the affected ext4 path.
• Ensure crash dump collection, persistent journald storage, and kernel panic telemetry are enabled on high-value Linux systems to support post-incident analysis.
• Because EPSS is currently low, stable, not KEV-listed, and no public exploit maturity is reported, handle as high-severity operational risk rather than confirmed active exploitation unless local evidence indicates otherwise.