From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,piaojun@huawei.com,mark@fasheh.com,junxiao.bi@oracle.com,joseph.qi@linux.alibaba.com,jlbec@evilplan.org,heming.zhao@suse.com,gechangwei@live.cn,zhanxusheng@xiaomi.com,akpm@linux-foundation.org
Subject: [merged mm-nonmm-stable] ocfs2-bound-check-dir-entries-in-the-readdir-re-validation-scan.patch removed from -mm tree
Date: Wed, 19 Aug 2026 19:55:38 -0700 [thread overview]
Message-ID: <20260820025538.DA8E61F000E9@smtp.kernel.org> (raw)
The quilt patch titled
Subject: ocfs2: bound-check dir entries in the readdir re-validation scan
has been removed from the -mm tree. Its filename was
ocfs2-bound-check-dir-entries-in-the-readdir-re-validation-scan.patch
This patch was dropped because it was merged into the mm-nonmm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Zhan Xusheng <zhanxusheng@xiaomi.com>
Subject: ocfs2: bound-check dir entries in the readdir re-validation scan
Date: Tue, 11 Aug 2026 10:43:36 +0800
Patch series "ocfs2: bound-check both readdir re-validation scans", v2.
This patch (of 2):
When the inode version changed since the last readdir(),
ocfs2_dir_foreach_blk_el() re-scans the directory block from its start to
relocate the current position:
for (i = 0; i < sb->s_blocksize && i < offset; ) {
de = (struct ocfs2_dir_entry *)(bh->b_data + i);
if (le16_to_cpu(de->rec_len) < OCFS2_DIR_REC_LEN(1))
break;
i += le16_to_cpu(de->rec_len);
}
i walks the block on rec_len values taken from the block itself and the
only thing tested is that rec_len is not too small, so a single bogus
rec_len leaves i anywhere in the block, including its last
OCFS2_DIR_REC_LEN(1) - 1 bytes. @offset comes from ctx->pos, which
userspace moves with lseek() on the directory fd, and decides how far the
walk gets.
Two bounds are missing, both of which ocfs2_check_dir_entry() applies for
the emit loop below.
de->rec_len sits at byte offset 8 within the entry, so dereferencing de in
that tail reads past the s_blocksize buffer. ocfs2_check_dir_entry()
declines to look at an entry that close to the end:
size - buf_offset < OCFS2_DIR_REC_LEN(1)
Nothing bounds i += rec_len either, so i can end up past the block. The
emit loop that follows is guarded by offset < sb->s_blocksize and does not
run, but
offset = i;
ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset;
runs first and ORs a value with bits above the block mask into ctx->pos,
corrupting the block number readdir() resumes from.
ocfs2_check_dir_entry() rejects that as "directory entry overrun":
next_offset = buf_offset + rlen;
... next_offset > size
Apply both bounds. For a consistent directory this changes nothing:
entries are at least OCFS2_DIR_REC_LEN(1) bytes and do not cross the end
of the block, so no valid entry is skipped.
Found by the sashiko review tool; fix approach suggested by Joseph Qi.
Link: https://lore.kernel.org/20260811024337.3972976-1-zhanxusheng@xiaomi.com
Link: https://sashiko.dev/#/patchset/20260806022044.167962-1-zhanxusheng@xiaomi.com
Link: https://lore.kernel.org/20260811024337.3972976-2-zhanxusheng@xiaomi.com
Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
Suggested-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Jun Piao <piaojun@huawei.com>
Cc: Heming Zhao <heming.zhao@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/ocfs2/dir.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/fs/ocfs2/dir.c~ocfs2-bound-check-dir-entries-in-the-readdir-re-validation-scan
+++ a/fs/ocfs2/dir.c
@@ -1945,7 +1945,10 @@ static int ocfs2_dir_foreach_blk_el(stru
* dirent right now. Scan from the start of the block
* to make sure. */
if (!inode_eq_iversion(inode, *f_version)) {
- for (i = 0; i < sb->s_blocksize && i < offset; ) {
+ for (i = 0; i + OCFS2_DIR_REC_LEN(1) <= sb->s_blocksize &&
+ i < offset;) {
+ unsigned int rec_len;
+
de = (struct ocfs2_dir_entry *) (bh->b_data + i);
/* It's too expensive to do a full
* dirent test each time round this
@@ -1953,10 +1956,11 @@ static int ocfs2_dir_foreach_blk_el(stru
* least that it is non-zero. A
* failure will be detected in the
* dirent test below. */
- if (le16_to_cpu(de->rec_len) <
- OCFS2_DIR_REC_LEN(1))
+ rec_len = le16_to_cpu(de->rec_len);
+ if (rec_len < OCFS2_DIR_REC_LEN(1) ||
+ i + rec_len > sb->s_blocksize)
break;
- i += le16_to_cpu(de->rec_len);
+ i += rec_len;
}
offset = i;
ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1))
_
Patches currently in -mm which might be from zhanxusheng@xiaomi.com are
reply other threads:[~2026-08-20 2:55 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=20260820025538.DA8E61F000E9@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=gechangwei@live.cn \
--cc=heming.zhao@suse.com \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=junxiao.bi@oracle.com \
--cc=mark@fasheh.com \
--cc=mm-commits@vger.kernel.org \
--cc=piaojun@huawei.com \
--cc=zhanxusheng@xiaomi.com \
/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.