From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,xmei5@asu.edu,stable@vger.kernel.org,mark@fasheh.com,joseph.qi@linux.alibaba.com,jlbec@evilplan.org,gkobakhi@asu.edu,akpm@linux-foundation.org
Subject: + ocfs2-fix-array-out-of-bound-access-in-__ocfs2_find_path.patch added to mm-nonmm-unstable branch
Date: Tue, 22 Sep 2026 19:33:41 -0700 [thread overview]
Message-ID: <20260923023341.7CDB41F000FF@smtp.kernel.org> (raw)
The patch titled
Subject: ocfs2: fix array out of bound access in __ocfs2_find_path()
has been added to the -mm mm-nonmm-unstable branch. Its filename is
ocfs2-fix-array-out-of-bound-access-in-__ocfs2_find_path.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/ocfs2-fix-array-out-of-bound-access-in-__ocfs2_find_path.patch
This patch will later appear in the mm-nonmm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days
------------------------------------------------------
From: Giorgi Kobakhia <gkobakhi@asu.edu>
Subject: ocfs2: fix array out of bound access in __ocfs2_find_path()
Date: Tue, 22 Sep 2026 13:21:59 -0700
__ocfs2_find_path() walks down the extent tree and records path by calling
find_path_ins(), which appends entry to path->p_node[]. It only has 5
spots.
A corrupted ocfs2 image whose extent block is pointing to itself causes
__ocfs2_find_path() descent endlessly, writing past the end of
path->p_node[] array.
UBSAN: array-index-out-of-bounds in fs/ocfs2/alloc.c:677:14
index 5 is out of range for type 'ocfs2_path_item [5]'
Call Trace:
<TASK>
find_path_ins (fs/ocfs2/alloc.c:677 fs/ocfs2/alloc.c:1914)
__ocfs2_find_path.constprop.0 (fs/ocfs2/alloc.c:1882)
ocfs2_commit_truncate (fs/ocfs2/alloc.c:1924 fs/ocfs2/alloc.c:7286)
ocfs2_truncate_file (fs/ocfs2/file.c:515)
ocfs2_setattr (fs/ocfs2/file.c:1224)
notify_change (fs/attr.c:556)
do_truncate (fs/open.c:68)
do_ftruncate (fs/open.c:194 (discriminator 1))
ksys_ftruncate (fs/open.c:206)
__x64_sys_ftruncate (fs/open.c:211 fs/open.c:209 fs/open.c:209)
Commit a406aff8c051 ("ocfs2: validate l_tree_depth to avoid out-of-bounds
access") already restricts el->l_tree_depth to be less than
OCFS2_MAX_PATH_DEPTH, which is equal to 5. However, does not handle the
infinite descent case.
Check if the el->l_tree_depth decreases on each descent. Maximum descents
are restricted to 4 and the path->p_node[] array does not overflow.
Assisted-by: LLM
Link: https://lore.kernel.org/20260922202159.2421642-1-gkobakhi@asu.edu
Fixes: dcd0538ff4e8 ("ocfs2: sparse b-tree support")
Signed-off-by: Giorgi Kobakhia <gkobakhi@asu.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tested-by: Xiang Mei <xmei5@asu.edu>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: <stable@vger.kernel.org>
---
fs/ocfs2/alloc.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/fs/ocfs2/alloc.c~ocfs2-fix-array-out-of-bound-access-in-__ocfs2_find_path
+++ a/fs/ocfs2/alloc.c
@@ -1817,6 +1817,7 @@ static int __ocfs2_find_path(struct ocfs
int i, ret = 0;
u32 range;
u64 blkno;
+ u32 prev_depth = OCFS2_MAX_PATH_DEPTH;
struct buffer_head *bh = NULL;
struct ocfs2_extent_block *eb;
struct ocfs2_extent_list *el;
@@ -1824,14 +1825,16 @@ static int __ocfs2_find_path(struct ocfs
el = root_el;
while (el->l_tree_depth) {
- if (unlikely(le16_to_cpu(el->l_tree_depth) >= OCFS2_MAX_PATH_DEPTH)) {
+ if (unlikely(le16_to_cpu(el->l_tree_depth) >= prev_depth)) {
ocfs2_error(ocfs2_metadata_cache_get_super(ci),
- "Owner %llu has invalid tree depth %u in extent list\n",
+ "Owner %llu has invalid tree depth %u in extent list (max %u)\n",
(unsigned long long)ocfs2_metadata_cache_owner(ci),
- le16_to_cpu(el->l_tree_depth));
+ le16_to_cpu(el->l_tree_depth), prev_depth - 1);
ret = -EROFS;
goto out;
}
+ prev_depth = le16_to_cpu(el->l_tree_depth);
+
if (!el->l_next_free_rec || !el->l_count) {
ocfs2_error(ocfs2_metadata_cache_get_super(ci),
"Owner %llu has empty extent list at depth %u\n"
_
Patches currently in -mm which might be from gkobakhi@asu.edu are
ocfs2-fix-array-out-of-bound-access-in-__ocfs2_find_path.patch
reply other threads:[~2026-09-23 2:33 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=20260923023341.7CDB41F000FF@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=gkobakhi@asu.edu \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=mark@fasheh.com \
--cc=mm-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=xmei5@asu.edu \
/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.