Cyber Resilience

CVE-2026-31598

Linux Kernel 4.6 – 6.6.136

Published
24 April 2026
Modified
01 June 2026
Patch / advisory
CVSS Score v3.1 7.5
Click a component to see what it means
Raw vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score 0.0043 36th percentile
Risk Priority 57 floored blend · peak EPSS

CVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.

Summary

CVE-2026-31598 is a high-severity Improper Locking (CWE-667) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.5 (High).

Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked at the 36th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

Deeper analysis AI-assisted summary

Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.

CVE-2026-31598 is a deadlock vulnerability in the Linux kernel's ocfs2 filesystem, stemming from an ABBA lock ordering violation between the orphan directory inode_lock and the ip_alloc_sem. In ocfs2_unlink, the locks are acquired in the order of orphan dir inode_lock followed by ip_alloc_sem, while ocfs2_dio_end_io_write acquires them in reverse: ip_alloc_sem first, then orphan dir inode_lock. This can lead to a deadlock when the operations execute concurrently on different CPUs, as detailed in the lock chains provided in the advisory.

A network-accessible, unauthenticated attacker with low attack complexity and no user interaction can exploit this vulnerability remotely (AV:N/AC:L/PR:N/UI:N/S:U), triggering the deadlock scenario. The attacker can cause a denial-of-service condition by inducing concurrent unlink and direct I/O end-write operations on affected ocfs2 volumes, resulting in high availability impact (C:N/I:N/A:H) with a CVSS v3.1 base score of 7.5. Successful exploitation hangs kernel processes involved, disrupting filesystem operations.

Mitigation is addressed in upstream Linux kernel stable releases via patches that reorder lock acquisition by moving ocfs2_del_inode_from_orphan outside the ip_alloc_sem critical section, as ip_alloc_sem protects allocation changes unrelated to orphan directory operations. Relevant commits include 2b884d52273c60c298bd570163e8053657bbaff6, 4b80b5a838a32437f2cae0662578bac216a2c51a, b02da26a992db0c0e2559acbda0fc48d4a2fd337, bc0fb5c7d54c78be43a536df0e20dee32adb27d3, and e049f7a9bd80b7319590789ea5e1c523d6339d91, available in kernel.org stable trees. Security practitioners should update to patched kernel versions using ocfs2.

EU & UK References

Vulnerability Data

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible deadlock between unlink and dio_end_io_write ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an…

more

ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key. Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir ocfs2_expand_inline_dir down_write(&oi->ip_alloc_sem) <- Lock B Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode) Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise Techniques

T1499 Endpoint Denial of Service Impact
Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users.
T1499.004 Application or System Exploitation Impact
Adversaries may exploit software vulnerabilities that can cause an application or system to crash and deny availability to users.
T1068 Exploitation for Privilege Escalation Privilege Escalation
Adversaries may exploit software vulnerabilities in an attempt to elevate privileges.
T1548 Abuse Elevation Control Mechanism Privilege Escalation
Adversaries may circumvent mechanisms designed to control privilege elevation to gain higher-level permissions.
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2025-22098Same product: Linux Linux Kernel
CVE-2024-36882Same product: Linux Linux Kernel
CVE-2024-46750Same product: Linux Linux Kernel
CVE-2026-23232Same product: Linux Linux Kernel
CVE-2024-43862Same product: Linux Linux Kernel
CVE-2025-22012Same product: Linux Linux Kernel
CVE-2024-40912Same product: Linux Linux Kernel
CVE-2025-22077Same product: Linux Linux Kernel
CVE-2024-35968Same product: Linux Linux Kernel
CVE-2026-53049Same product: Linux Linux Kernel

Affected Assets

linux
linux kernel
4.6 — 6.6.136 · 6.7 — 6.12.83 · 6.13 — 6.18.24

Mitigating Controls

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly include code reviews, static analysis, and concurrency standards that prevent improper locking.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

finds

Security testing can detect race conditions and locking errors before release.

prevents

Secure development lifecycle includes concurrency and locking requirements that reduce improper locking defects.

prevents

Application security requirements can mandate proper lock acquisition/release patterns.

prevents

Secure architecture principles address thread-safety and resource synchronization.

prevents

Secure coding standards directly prohibit missing or incorrect lock usage.

prevents

Change management may catch locking issues introduced by modifications but does not prevent the weakness itself.

References