linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: cel@kernel.org
To: Hugh Dickins <hughd@google.com>,
	Andrew Morten <akpm@linux-foundation.org>,
	Christian Brauner <brauner@kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sasha Levin <sashal@kernel.org>
Cc: <linux-fsdevel@vger.kernel.org>, <stable@vger.kernel.org>,
	<linux-mm@kvack.org>,
	yukuai3@huawei.com, yangerkun@huawei.com,
	Chuck Lever <chuck.lever@oracle.com>
Subject: [RFC PATCH v6.6 09/10] libfs: Replace simple_offset end-of-directory detection
Date: Fri, 24 Jan 2025 14:19:44 -0500	[thread overview]
Message-ID: <20250124191946.22308-10-cel@kernel.org> (raw)
In-Reply-To: <20250124191946.22308-1-cel@kernel.org>

From: Chuck Lever <chuck.lever@oracle.com>

[ Upstream commit 68a3a65003145644efcbb651e91db249ccd96281 ]

According to getdents(3), the d_off field in each returned directory
entry points to the next entry in the directory. The d_off field in
the last returned entry in the readdir buffer must contain a valid
offset value, but if it points to an actual directory entry, then
readdir/getdents can loop.

This patch introduces a specific fixed offset value that is placed
in the d_off field of the last entry in a directory. Some user space
applications assume that the EOD offset value is larger than the
offsets of real directory entries, so the largest valid offset value
is reserved for this purpose. This new value is never allocated by
simple_offset_add().

When ->iterate_dir() returns, getdents{64} inserts the ctx->pos
value into the d_off field of the last valid entry in the readdir
buffer. When it hits EOD, offset_readdir() sets ctx->pos to the EOD
offset value so the last entry is updated to point to the EOD marker.

When trying to read the entry at the EOD offset, offset_readdir()
terminates immediately.

It is worth noting that using a Maple tree for directory offset
value allocation does not guarantee a 63-bit range of values --
on platforms where "long" is a 32-bit type, the directory offset
value range is still 0..(2^31 - 1). For broad compatibility with
32-bit user space, the largest tmpfs directory cookie value is now
S32_MAX.

Fixes: 796432efab1e ("libfs: getdents() should return 0 after reaching EOD")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Link: https://lore.kernel.org/r/20241228175522.1854234-5-cel@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
[ 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, 21 insertions(+), 16 deletions(-)

diff --git a/fs/libfs.c b/fs/libfs.c
index 082bacf0b9e6..d546f3f0c036 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -239,9 +239,15 @@ const struct inode_operations simple_dir_inode_operations = {
 };
 EXPORT_SYMBOL(simple_dir_inode_operations);
 
-/* 0 is '.', 1 is '..', so always start with offset 2 or more */
+/* simple_offset_add() never assigns these to a dentry */
 enum {
-	DIR_OFFSET_MIN	= 2,
+	DIR_OFFSET_EOD		= S32_MAX,
+};
+
+/* simple_offset_add() allocation range */
+enum {
+	DIR_OFFSET_MIN		= 2,
+	DIR_OFFSET_MAX		= DIR_OFFSET_EOD - 1,
 };
 
 static void offset_set(struct dentry *dentry, u32 offset)
@@ -278,7 +284,8 @@ void simple_offset_init(struct offset_ctx *octx)
  */
 int simple_offset_add(struct offset_ctx *octx, struct dentry *dentry)
 {
-	static const struct xa_limit limit = XA_LIMIT(DIR_OFFSET_MIN, U32_MAX);
+	static const struct xa_limit limit = XA_LIMIT(DIR_OFFSET_MIN,
+						      DIR_OFFSET_MAX);
 	u32 offset;
 	int ret;
 
@@ -442,8 +449,6 @@ static loff_t offset_dir_llseek(struct file *file, loff_t offset, int whence)
 		return -EINVAL;
 	}
 
-	/* In this case, ->private_data is protected by f_pos_lock */
-	file->private_data = NULL;
 	return vfs_setpos(file, offset, U32_MAX);
 }
 
@@ -453,7 +458,7 @@ static struct dentry *offset_find_next(struct offset_ctx *octx, loff_t offset)
 	XA_STATE(xas, &octx->xa, offset);
 
 	rcu_read_lock();
-	child = xas_next_entry(&xas, U32_MAX);
+	child = xas_next_entry(&xas, DIR_OFFSET_MAX);
 	if (!child)
 		goto out;
 	spin_lock(&child->d_lock);
@@ -474,7 +479,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)
 {
 	struct offset_ctx *octx = inode->i_op->get_offset_ctx(inode);
 	struct dentry *dentry;
@@ -482,7 +487,7 @@ static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx)
 	while (true) {
 		dentry = offset_find_next(octx, ctx->pos);
 		if (!dentry)
-			return ERR_PTR(-ENOENT);
+			goto out_eod;
 
 		if (!offset_dir_emit(ctx, dentry)) {
 			dput(dentry);
@@ -492,7 +497,10 @@ static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx)
 		ctx->pos = dentry2offset(dentry) + 1;
 		dput(dentry);
 	}
-	return NULL;
+	return;
+
+out_eod:
+	ctx->pos = DIR_OFFSET_EOD;
 }
 
 /**
@@ -512,6 +520,8 @@ static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx)
  *
  * On return, @ctx->pos contains an offset that will read the next entry
  * in this directory when offset_readdir() is called again with @ctx.
+ * Caller places this value in the d_off field of the last entry in the
+ * user's buffer.
  *
  * Return values:
  *   %0 - Complete
@@ -524,13 +534,8 @@ static int offset_readdir(struct file *file, struct dir_context *ctx)
 
 	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);
+	if (ctx->pos != DIR_OFFSET_EOD)
+		offset_iterate_dir(d_inode(dir), ctx);
 	return 0;
 }
 
-- 
2.47.0



  parent reply	other threads:[~2025-01-24 19:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-24 19:19 [RFC PATCH v6.6 00/10] Address CVE-2024-46701 cel
2025-01-24 19:19 ` [RFC PATCH v6.6 01/10] libfs: Re-arrange locking in offset_iterate_dir() cel
2025-01-24 19:19 ` [RFC PATCH v6.6 02/10] libfs: Define a minimum directory offset cel
2025-01-30  8:59   ` Patch "libfs: Define a minimum directory offset" has been added to the 6.6-stable tree gregkh
2025-01-24 19:19 ` [RFC PATCH v6.6 03/10] libfs: Add simple_offset_empty() cel
2025-01-30  8:59   ` Patch "libfs: Add simple_offset_empty()" has been added to the 6.6-stable tree gregkh
2025-01-24 19:19 ` [RFC PATCH v6.6 04/10] libfs: Fix simple_offset_rename_exchange() cel
2025-01-30  8:59   ` Patch "libfs: Fix simple_offset_rename_exchange()" has been added to the 6.6-stable tree gregkh
2025-01-24 19:19 ` [RFC PATCH v6.6 05/10] libfs: Add simple_offset_rename() API cel
2025-01-30  8:59   ` Patch "libfs: Add simple_offset_rename() API" has been added to the 6.6-stable tree gregkh
2025-01-24 19:19 ` [RFC PATCH v6.6 06/10] shmem: Fix shmem_rename2() cel
2025-01-30  8:59   ` Patch "shmem: Fix shmem_rename2()" has been added to the 6.6-stable tree gregkh
2025-01-24 19:19 ` [RFC PATCH v6.6 07/10] libfs: Return ENOSPC when the directory offset range is exhausted cel
2025-01-30  8:59   ` Patch "libfs: Return ENOSPC when the directory offset range is exhausted" has been added to the 6.6-stable tree gregkh
2025-01-24 19:19 ` [RFC PATCH v6.6 08/10] Revert "libfs: Add simple_offset_empty()" cel
2025-01-30  8:59   ` Patch "Revert "libfs: Add simple_offset_empty()"" has been added to the 6.6-stable tree gregkh
2025-01-24 19:19 ` cel [this message]
2025-01-30  8:59   ` Patch "libfs: Replace simple_offset end-of-directory detection" " gregkh
2025-01-24 19:19 ` [RFC PATCH v6.6 10/10] libfs: Use d_children list to iterate simple_offset directories cel
2025-01-30  8:59   ` Patch "libfs: Use d_children list to iterate simple_offset directories" has been added to the 6.6-stable tree gregkh
2025-01-29 13:55 ` [RFC PATCH v6.6 00/10] Address CVE-2024-46701 Chuck Lever
2025-01-29 14:50   ` Greg Kroah-Hartman
2025-01-29 15:06     ` Chuck Lever
2025-01-29 15:21       ` Greg Kroah-Hartman
2025-01-29 16:37         ` Chuck Lever
2025-01-30  8:45           ` Greg Kroah-Hartman
2025-01-30 14:02             ` Chuck Lever
2025-01-30 14:24               ` Greg Kroah-Hartman

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=20250124191946.22308-10-cel@kernel.org \
    --to=cel@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hughd@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yangerkun@huawei.com \
    --cc=yukuai3@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox