From: Ilya Dryomov <idryomov@gmail.com>
To: stable@vger.kernel.org
Cc: patches@lists.linux.dev,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Xiubo Li <xiubli@redhat.com>,
Patrick Donnelly <pdonnell@redhat.com>,
Milind Changire <mchangir@redhat.com>,
Sasha Levin <sashal@kernel.org>
Subject: [PATCH 6.6] ceph: give up on paths longer than PATH_MAX
Date: Tue, 7 Jan 2025 16:50:08 +0100 [thread overview]
Message-ID: <20250107155010.2658845-1-idryomov@gmail.com> (raw)
From: Max Kellermann <max.kellermann@ionos.com>
commit 550f7ca98ee028a606aa75705a7e77b1bd11720f upstream.
If the full path to be built by ceph_mdsc_build_path() happens to be
longer than PATH_MAX, then this function will enter an endless (retry)
loop, effectively blocking the whole task. Most of the machine
becomes unusable, making this a very simple and effective DoS
vulnerability.
I cannot imagine why this retry was ever implemented, but it seems
rather useless and harmful to me. Let's remove it and fail with
ENAMETOOLONG instead.
Cc: stable@vger.kernel.org
Reported-by: Dario Weißer <dario@cure53.de>
Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
Reviewed-by: Alex Markuze <amarkuze@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
[idryomov@gmail.com: backport to 6.6: pr_warn() is still in use]
---
fs/ceph/mds_client.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
index 11289ce8a8cc..dfa1b3c82b53 100644
--- a/fs/ceph/mds_client.c
+++ b/fs/ceph/mds_client.c
@@ -2713,12 +2713,11 @@ char *ceph_mdsc_build_path(struct ceph_mds_client *mdsc, struct dentry *dentry,
if (pos < 0) {
/*
- * A rename didn't occur, but somehow we didn't end up where
- * we thought we would. Throw a warning and try again.
+ * The path is longer than PATH_MAX and this function
+ * cannot ever succeed. Creating paths that long is
+ * possible with Ceph, but Linux cannot use them.
*/
- pr_warn("build_path did not end path lookup where expected (pos = %d)\n",
- pos);
- goto retry;
+ return ERR_PTR(-ENAMETOOLONG);
}
*pbase = base;
--
2.46.1
next reply other threads:[~2025-01-07 15:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-07 15:50 Ilya Dryomov [this message]
2025-01-08 19:49 ` [PATCH 6.6] ceph: give up on paths longer than PATH_MAX Sasha Levin
2025-01-09 11:46 ` 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=20250107155010.2658845-1-idryomov@gmail.com \
--to=idryomov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=mchangir@redhat.com \
--cc=patches@lists.linux.dev \
--cc=pdonnell@redhat.com \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=xiubli@redhat.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