CVE-2026-31598
Linux Kernel 4.6 – 6.6.136
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HCVSS 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
- 🇪🇺 ENISA EUVD: EUVD-2026-25491
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
CVEs Like This One
Affected Assets
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.
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.
Security testing can detect race conditions and locking errors before release.
Secure development lifecycle includes concurrency and locking requirements that reduce improper locking defects.
Application security requirements can mandate proper lock acquisition/release patterns.
Secure architecture principles address thread-safety and resource synchronization.
Secure coding standards directly prohibit missing or incorrect lock usage.
Change management may catch locking issues introduced by modifications but does not prevent the weakness itself.