From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-80879: ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write
Date: Fri, 4 Sep 2026 18:46:46 +0200 [thread overview]
Message-ID: <2026090436-CVE-2026-80879-2414@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write
A circular locking dependency involves INODE_ALLOC_SYSTEM_INODE,
EXTENT_ALLOC_SYSTEM_INODE, and ORPHAN_DIR_SYSTEM_INODE.
1. ocfs2_mknod() acquires INODE_ALLOC then EXTENT_ALLOC.
2. ocfs2_dio_end_io_write() acquires EXTENT_ALLOC for unwritten
extents, then ORPHAN_DIR via ocfs2_del_inode_from_orphan() while still
holding EXTENT_ALLOC.
3. ocfs2_wipe_inode() acquires ORPHAN_DIR then INODE_ALLOC via
ocfs2_remove_inode.
Break the cycle in ocfs2_dio_end_io_write() by freeing the allocation
contexts (releasing EXTENT_ALLOC) before acquiring ORPHAN_DIR.
WARNING: possible circular locking dependency detected
------------------------------------------------------
is trying to acquire lock:
ffff8881e78b33a0
(&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]){+.+.}-{4:4}, at:
ocfs2_evict_inode+0x1539/0x43b0 fs/ocfs2/inode.c:1299
but task is already holding lock:
ffff8881e78b4fa0
(&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]){+.+.}-{4:4}, at:
ocfs2_evict_inode+0xe97/0x43b0 fs/ocfs2/inode.c:1299
the existing dependency chain (in reverse order) is:
-> #2 (&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]){+.+.}-{4:4}:
inode_lock include/linux/fs.h:1029 [inline]
ocfs2_del_inode_from_orphan+0x12e/0x7a0 fs/ocfs2/namei.c:2728
ocfs2_dio_end_io+0xf9c/0x1370 fs/ocfs2/aops.c:2418
dio_complete+0x25b/0x790 fs/direct-io.c:281
-> #1 (&ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE]){+.+.}-{4:4}:
inode_lock include/linux/fs.h:1029 [inline]
ocfs2_reserve_suballoc_bits+0x16d/0x4840 fs/ocfs2/suballoc.c:882
ocfs2_reserve_new_metadata_blocks+0x415/0x9a0
fs/ocfs2/suballoc.c:1078
ocfs2_mknod+0x10f3/0x2260 fs/ocfs2/namei.c:351
-> #0 (&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]){+.+.}-{4:4}:
__lock_acquire+0x15a5/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5868
down_write+0x96/0x200 kernel/locking/rwsem.c:1625
inode_lock include/linux/fs.h:1029 [inline]
ocfs2_remove_inode fs/ocfs2/inode.c:733 [inline]
ocfs2_wipe_inode fs/ocfs2/inode.c:896 [inline]
ocfs2_delete_inode fs/ocfs2/inode.c:1157 [inline]
ocfs2_evict_inode+0x1539/0x43b0 fs/ocfs2/inode.c:1299
Chain exists of:
&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE] -->
&ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE] -->
&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]);
lock(&ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE]);
lock(&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]);
lock(&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]);
*** DEADLOCK ***
The Linux kernel CVE team has assigned CVE-2026-80879 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.10.258 with commit 97c03c0e9f73a5049794b3c69ee60fb5e8b0ebd8 and fixed in 5.10.261 with commit f0ae0a6ca87dc2d4a789f71cdedb808ba6c16990
Issue introduced in 5.15.209 with commit 1e99bb19994246514d63e656492904176f9d5edd and fixed in 5.15.212 with commit 137e8b4823a9a11928428d4ec0a0cacb2f50a769
Issue introduced in 6.1.175 with commit 91e05ac2336d00d5b99fc774be4bd50039084796 and fixed in 6.1.178 with commit 4273548e418bd935430d35e9d052870f323441f3
Issue introduced in 6.6.140 with commit 886f97fa59d0bbfa9859fb1a66dd9e014b522d89 and fixed in 6.6.145 with commit 49b34bd3ad69611af03590a23abf2cda9ac1073d
Issue introduced in 6.12.86 with commit ea5bb1d20da756e4f41a48dad42b2e7d6e73f71e and fixed in 6.12.97 with commit ff187c502b39389b0d732cb7050a3db8e5ebfcd6
Issue introduced in 6.18.27 with commit 3c636a3edca9c3f180b3079f94fe7e115730d9c6 and fixed in 6.18.40 with commit ae1f3460833d3e427420ab260278ec0e45d68c86
Issue introduced in 7.1 with commit d647c5b2fbf81560818dacade360abc8c00a9665 and fixed in 7.1.5 with commit f3dd1e534e9de64669415f8239e0094afecfed78
Issue introduced in 7.1 with commit d647c5b2fbf81560818dacade360abc8c00a9665 and fixed in 7.2 with commit ff6f26c58421614b02694ac9d219ac61d924bc68
Issue introduced in 7.0.4 with commit 069c3fb310e9336cf48cfdf8748a32c29fd0193d
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-80879
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
fs/ocfs2/aops.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/f0ae0a6ca87dc2d4a789f71cdedb808ba6c16990
https://git.kernel.org/stable/c/137e8b4823a9a11928428d4ec0a0cacb2f50a769
https://git.kernel.org/stable/c/4273548e418bd935430d35e9d052870f323441f3
https://git.kernel.org/stable/c/49b34bd3ad69611af03590a23abf2cda9ac1073d
https://git.kernel.org/stable/c/ff187c502b39389b0d732cb7050a3db8e5ebfcd6
https://git.kernel.org/stable/c/ae1f3460833d3e427420ab260278ec0e45d68c86
https://git.kernel.org/stable/c/f3dd1e534e9de64669415f8239e0094afecfed78
https://git.kernel.org/stable/c/ff6f26c58421614b02694ac9d219ac61d924bc68
reply other threads:[~2026-09-04 16:49 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026090436-CVE-2026-80879-2414@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.