From: cel@kernel.org
To: <stable@vger.kernel.org>
Cc: yukuai1@huaweicloud.com, harry.wentland@amd.com,
sunpeng.li@amd.com, Rodrigo.Siqueira@amd.com,
alexander.deucher@amd.com, christian.koenig@amd.com,
Xinhui.Pan@amd.com, airlied@gmail.com, daniel@ffwll.ch,
viro@zeniv.linux.org.uk, brauner@kernel.org,
Liam.Howlett@oracle.com, akpm@linux-foundation.org,
hughd@google.com, willy@infradead.org,
gregkh@linuxfoundation.org, sashal@kernel.org,
srinivasan.shanmugam@amd.com, chiahsuan.chung@amd.com,
mingo@kernel.org, mgorman@techsingularity.net,
yukuai3@huawei.com, chengming.zhou@linux.dev,
zhangpeng.00@bytedance.com, amd-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, maple-tree@lists.infradead.org,
linux-mm@kvack.org, yi.zhang@huawei.com, yangerkun@huawei.com,
Chuck Lever <chuck.lever@oracle.com>
Subject: [RFC PATCH 6/6 6.6] libfs: fix infinite directory reads for offset dir
Date: Sun, 10 Nov 2024 19:52:42 -0500 [thread overview]
Message-ID: <20241111005242.34654-7-cel@kernel.org> (raw)
In-Reply-To: <20241111005242.34654-1-cel@kernel.org>
From: yangerkun <yangerkun@huawei.com>
[ Upstream commit 64a7ce76fb901bf9f9c36cf5d681328fc0fd4b5a ]
After we switch tmpfs dir operations from simple_dir_operations to
simple_offset_dir_operations, every rename happened will fill new dentry
to dest dir's maple tree(&SHMEM_I(inode)->dir_offsets->mt) with a free
key starting with octx->newx_offset, and then set newx_offset equals to
free key + 1. This will lead to infinite readdir combine with rename
happened at the same time, which fail generic/736 in xfstests(detail show
as below).
1. create 5000 files(1 2 3...) under one dir
2. call readdir(man 3 readdir) once, and get one entry
3. rename(entry, "TEMPFILE"), then rename("TEMPFILE", entry)
4. loop 2~3, until readdir return nothing or we loop too many
times(tmpfs break test with the second condition)
We choose the same logic what commit 9b378f6ad48cf ("btrfs: fix infinite
directory reads") to fix it, record the last_index when we open dir, and
do not emit the entry which index >= last_index. The file->private_data
now used in offset dir can use directly to do this, and we also update
the last_index when we llseek the dir file.
Fixes: a2e459555c5f ("shmem: stable directory offsets")
Signed-off-by: yangerkun <yangerkun@huawei.com>
Link: https://lore.kernel.org/r/20240731043835.1828697-1-yangerkun@huawei.com
Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
[brauner: only update last_index after seek when offset is zero like Jan suggested]
Signed-off-by: Christian Brauner <brauner@kernel.org>
Link: https://nvd.nist.gov/vuln/detail/CVE-2024-46701
[ cel: adjusted to apply to origin/linux-6.6.y ]
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
fs/libfs.c | 37 +++++++++++++++++++++++++------------
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/fs/libfs.c b/fs/libfs.c
index a87005c89534..b59ff0dfea1f 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -449,6 +449,14 @@ void simple_offset_destroy(struct offset_ctx *octx)
xa_destroy(&octx->xa);
}
+static int offset_dir_open(struct inode *inode, struct file *file)
+{
+ struct offset_ctx *ctx = inode->i_op->get_offset_ctx(inode);
+
+ file->private_data = (void *)ctx->next_offset;
+ return 0;
+}
+
/**
* offset_dir_llseek - Advance the read position of a directory descriptor
* @file: an open directory whose position is to be updated
@@ -462,6 +470,9 @@ void simple_offset_destroy(struct offset_ctx *octx)
*/
static loff_t offset_dir_llseek(struct file *file, loff_t offset, int whence)
{
+ struct inode *inode = file->f_inode;
+ struct offset_ctx *ctx = inode->i_op->get_offset_ctx(inode);
+
switch (whence) {
case SEEK_CUR:
offset += file->f_pos;
@@ -475,8 +486,9 @@ static loff_t offset_dir_llseek(struct file *file, loff_t offset, int whence)
}
/* In this case, ->private_data is protected by f_pos_lock */
- file->private_data = NULL;
- return vfs_setpos(file, offset, U32_MAX);
+ if (!offset)
+ file->private_data = (void *)ctx->next_offset;
+ return vfs_setpos(file, offset, LONG_MAX);
}
static struct dentry *offset_find_next(struct xa_state *xas)
@@ -505,7 +517,7 @@ static bool offset_dir_emit(struct dir_context *ctx, struct dentry *dentry)
inode->i_ino, fs_umode_to_dtype(inode->i_mode));
}
-static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx)
+static void offset_iterate_dir(struct inode *inode, struct dir_context *ctx, long last_index)
{
struct offset_ctx *so_ctx = inode->i_op->get_offset_ctx(inode);
XA_STATE(xas, &so_ctx->xa, ctx->pos);
@@ -514,17 +526,21 @@ static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx)
while (true) {
dentry = offset_find_next(&xas);
if (!dentry)
- return ERR_PTR(-ENOENT);
+ return;
+
+ if (dentry2offset(dentry) >= last_index) {
+ dput(dentry);
+ return;
+ }
if (!offset_dir_emit(ctx, dentry)) {
dput(dentry);
- break;
+ return;
}
dput(dentry);
ctx->pos = xas.xa_index + 1;
}
- return NULL;
}
/**
@@ -551,22 +567,19 @@ static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx)
static int offset_readdir(struct file *file, struct dir_context *ctx)
{
struct dentry *dir = file->f_path.dentry;
+ long last_index = (long)file->private_data;
lockdep_assert_held(&d_inode(dir)->i_rwsem);
if (!dir_emit_dots(file, ctx))
return 0;
- /* In this case, ->private_data is protected by f_pos_lock */
- if (ctx->pos == DIR_OFFSET_MIN)
- file->private_data = NULL;
- else if (file->private_data == ERR_PTR(-ENOENT))
- return 0;
- file->private_data = offset_iterate_dir(d_inode(dir), ctx);
+ offset_iterate_dir(d_inode(dir), ctx, last_index);
return 0;
}
const struct file_operations simple_offset_dir_operations = {
+ .open = offset_dir_open,
.llseek = offset_dir_llseek,
.iterate_shared = offset_readdir,
.read = generic_read_dir,
--
2.47.0
next prev parent reply other threads:[~2024-11-11 0:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-11 0:52 [RFC PATCH 0/6 6.6] Address rename/readdir bugs in fs/libfs.c cel
2024-11-11 0:52 ` [RFC PATCH 1/6 6.6] libfs: Define a minimum directory offset cel
2024-11-11 0:52 ` [RFC PATCH 2/6 6.6] libfs: Add simple_offset_empty() cel
2024-11-11 0:52 ` [RFC PATCH 3/6 6.6] libfs: Fix simple_offset_rename_exchange() cel
2024-11-11 0:52 ` [RFC PATCH 4/6 6.6] libfs: Add simple_offset_rename() API cel
2024-11-11 0:52 ` [RFC PATCH 5/6 6.6] shmem: Fix shmem_rename2() cel
2024-11-11 0:52 ` cel [this message]
2024-11-11 2:36 ` [RFC PATCH 6/6 6.6] libfs: fix infinite directory reads for offset dir Yu Kuai
2024-11-11 14:39 ` Chuck Lever III
2024-11-11 15:20 ` yangerkun
2024-11-11 15:34 ` Chuck Lever III
2024-11-12 3:43 ` yangerkun
2024-11-12 15:37 ` Chuck Lever III
2024-11-13 15:17 ` Chuck Lever
2024-11-16 7:22 ` Yu Kuai
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=20241111005242.34654-7-cel@kernel.org \
--to=cel@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=Rodrigo.Siqueira@amd.com \
--cc=Xinhui.Pan@amd.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=brauner@kernel.org \
--cc=chengming.zhou@linux.dev \
--cc=chiahsuan.chung@amd.com \
--cc=christian.koenig@amd.com \
--cc=chuck.lever@oracle.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=harry.wentland@amd.com \
--cc=hughd@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maple-tree@lists.infradead.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@kernel.org \
--cc=sashal@kernel.org \
--cc=srinivasan.shanmugam@amd.com \
--cc=stable@vger.kernel.org \
--cc=sunpeng.li@amd.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai1@huaweicloud.com \
--cc=yukuai3@huawei.com \
--cc=zhangpeng.00@bytedance.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.