Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-31598

CVE-2026-31598: Linux Kernel Race Condition Vulnerability

CVE-2026-31598 is a race condition flaw in the Linux Kernel ocfs2 subsystem that can trigger a deadlock between unlink and dio_end_io_write operations. This article covers technical details, affected versions, and mitigation.

Updated:

CVE-2026-31598 Overview

CVE-2026-31598 is a locking flaw in the Linux kernel's Oracle Cluster File System version 2 (ocfs2) implementation. The vulnerability is an ABBA lock ordering violation between ocfs2_unlink and ocfs2_dio_end_io_write. The two code paths acquire the orphan directory inode_lock and the ip_alloc_sem semaphore in opposite orders. Concurrent execution can deadlock both threads, blocking filesystem operations and producing a denial-of-service condition. The issue is classified as CWE-667: Improper Locking and affects the upstream Linux kernel. Fixes have been merged across multiple stable branches.

Critical Impact

Concurrent unlink and direct I/O write completion on an ocfs2 volume can deadlock kernel threads, hanging filesystem operations and impacting availability.

Affected Products

  • Linux kernel (upstream) — ocfs2 filesystem subsystem
  • Linux kernel stable branches prior to commits 2b884d52, 4b80b5a8, b02da26a, bc0fb5c7, e049f7a9, and f9fb1a7b
  • Distributions shipping vulnerable kernels with ocfs2 enabled

Discovery Timeline

  • 2026-04-24 - CVE-2026-31598 published to NVD
  • 2026-04-29 - Last updated in NVD database

Technical Details for CVE-2026-31598

Vulnerability Analysis

The defect lives in two ocfs2 code paths that share two synchronization primitives but acquire them in opposite orders. ocfs2_unlink calls ocfs2_prepare_orphan_dir, which takes inode_lock(orphan_dir_inode) first. It then descends into ocfs2_extend_dir and ocfs2_expand_inline_dir, where it acquires ip_alloc_sem via down_write. The direct I/O completion path ocfs2_dio_end_io_write reverses this order. It acquires ip_alloc_sem first, then calls ocfs2_del_inode_from_orphan, which takes inode_lock(orphan_dir_inode). When two CPUs execute these paths concurrently, each thread holds the lock the other needs and neither can progress.

Root Cause

The root cause is inconsistent lock ordering between the orphan directory inode lock class ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and the per-inode allocation semaphore lock class ocfs2_file_ip_alloc_sem_key. The ip_alloc_sem semaphore exists to protect extent allocation changes. The orphan list manipulation in ocfs2_del_inode_from_orphan is unrelated to allocation state. Holding ip_alloc_sem across that call is unnecessary and creates the ABBA condition. The upstream fix moves ocfs2_del_inode_from_orphan outside the ip_alloc_sem critical section.

Attack Vector

Triggering the deadlock requires concurrent filesystem activity on an ocfs2 volume: an unlink operation in one thread and a direct I/O write completion targeting an orphaned inode in another. A local user with write access to an ocfs2 mount can produce the workload. Exploitation does not yield code execution or data disclosure. Impact is limited to availability: hung tasks, blocked I/O, and potential cascading stalls on the cluster filesystem.

No public proof-of-concept code is available for this issue. Refer to the upstream commits listed under Vendor Advisories for the exact source-level change.

Detection Methods for CVE-2026-31598

Indicators of Compromise

  • Kernel hung task warnings in dmesg or /var/log/messages referencing ocfs2_unlink, ocfs2_prepare_orphan_dir, or ocfs2_dio_end_io_write in the stuck task stack.
  • lockdep splats reporting circular dependency between ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key (on kernels with CONFIG_PROVE_LOCKING).
  • Processes stuck in D (uninterruptible sleep) state performing I/O against an ocfs2 mount.

Detection Strategies

  • Enable CONFIG_PROVE_LOCKING and CONFIG_DEBUG_LOCK_ALLOC in test environments to surface the ABBA pattern before deployment.
  • Monitor kernel ring buffer for INFO: task <name>:<pid> blocked for more than 120 seconds messages tied to ocfs2 call stacks.
  • Inventory all hosts mounting ocfs2 and correlate against running kernel versions to identify systems missing the fix commits.

Monitoring Recommendations

  • Forward dmesg and /var/log/kern.log to a centralized log platform and alert on hung_task_timeout_secs events.
  • Track D-state process counts per host; sustained increases on ocfs2 clients warrant investigation.
  • Use /proc/<pid>/stack snapshots from monitoring agents to capture call traces during stalls for root-cause analysis.

How to Mitigate CVE-2026-31598

Immediate Actions Required

  • Identify all systems running ocfs2 and confirm their kernel version against the fixed commits listed by upstream.
  • Schedule kernel updates to a stable release containing one of the fix commits: 2b884d52, 4b80b5a8, b02da26a, bc0fb5c7, e049f7a9, or f9fb1a7b.
  • On clustered deployments, plan rolling reboots to apply patched kernels without losing quorum.

Patch Information

The fix moves ocfs2_del_inode_from_orphan outside the ip_alloc_sem write section so that the orphan directory inode_lock is never acquired while holding ip_alloc_sem. Apply a distribution kernel update that incorporates the upstream patches. See Kernel Git Commit b02da26a and the related stable backports 4b80b5a8, 2b884d52, bc0fb5c7, e049f7a9, and f9fb1a7b.

Workarounds

  • Where feasible, avoid concurrent unlink operations and direct I/O writes against orphaned inodes on the same ocfs2 volume until patched.
  • Migrate workloads off ocfs2 to a filesystem unaffected by this defect if patching cannot be scheduled promptly.
  • Increase kernel.hung_task_timeout_secs only as a diagnostic aid; this does not resolve the deadlock and should not be treated as a fix.
bash
# Verify the running kernel and check for ocfs2 module use
uname -r
lsmod | grep ocfs2

# Inspect mounted ocfs2 filesystems
mount -t ocfs2

# Look for hung task and lockdep evidence
dmesg -T | grep -E 'hung_task|ocfs2|lockdep|possible circular'

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.