From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
To: "idryomov@gmail.com" <idryomov@gmail.com>,
Alex Markuze <amarkuze@redhat.com>,
"slava@dubeyko.com" <slava@dubeyko.com>,
"mishra.dhiraj95@gmail.com" <mishra.dhiraj95@gmail.com>
Cc: "raphael.zimmer@tu-ilmenau.de" <raphael.zimmer@tu-ilmenau.de>,
"w@1wt.eu" <w@1wt.eu>,
"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"security@kernel.org" <security@kernel.org>
Subject: Re: [PATCH v5] libceph, ceph: reject oversized mon and MDS data segments
Date: Fri, 8 May 2026 18:18:37 +0000 [thread overview]
Message-ID: <46a34e693aa1ba1e06108a80f5a14da320c7c284.camel@ibm.com> (raw)
In-Reply-To: <20260507191919.4985-1-mishra.dhiraj95@gmail.com>
On Thu, 2026-05-07 at 23:19 +0400, Dhiraj Mishra wrote:
> Monitor and MDS messages can be allocated with only front-buffer storage
> and no data items. The messenger receive path copies the wire header
> into the selected ceph_msg and later uses hdr.data_len to decide whether
> to initialize a data cursor.
>
> If a malicious or compromised peer advertises a non-zero data segment for
> one of these front-only messages, the receive path can call
> ceph_msg_data_cursor_init() with length greater than msg->data_length and
> hit its BUG_ON() checks, crashing the client kernel.
>
> I verified the monitor issue against v7.1-rc1-123-ge75a43c7cec4. The
> msgr2 trigger path is present since commit cd1a677cad99 ("libceph,
> ceph: implement msgr2.1 protocol (crc and secure modes)"), which is
> contained in v5.11-rc1 and later. The allocator patterns are older, but
> I have not tested older msgr1-only kernels.
>
> A concrete monitor trigger is a monitor connection over msgr2 after
> CEPH_CON_S_OPEN where a FRAME_TAG_MESSAGE contains a monitor reply type
> handled by mon_alloc_msg(), a valid front_len for that message type and
> data_len = 1. CEPH_MSG_MON_MAP is one such example: the message is
> allocated with ceph_msg_new(), leaving msg->data_length and
> msg->num_data_items as zero.
>
> The MDS allocation path has the same issue: mds_alloc_msg() allocates the
> incoming message with ceph_msg_new(type, front_len, GFP_NOFS, false),
> leaving msg->data_length as zero for a front-only message selected from
> an attacker-controlled wire header.
>
> Reject monitor and MDS messages whose wire data segment is larger than
> the data backing allocated for the selected ceph_msg, mirroring the
> existing OSD reply hardening.
>
> Fixes: 53ded495c6ac ("libceph: define mds_alloc_msg() method")
> Fixes: cd1a677cad99 ("libceph, ceph: implement msgr2.1 protocol (crc and secure modes)")
> Signed-off-by: Dhiraj Mishra <mishra.dhiraj95@gmail.com>
> ---
> v5:
> - Restructure mon_alloc_msg() control flow per review.
> - Return early for unknown types and front-buffer reallocation failure.
> - Keep the data_len guard on the final message allocation.
>
> v4:
> - Add the same oversized data_len guard to the MDS allocation path.
>
> v3:
> - Remove the impossible !req->reply check for generic requests.
> - Use pr_warn_ratelimited() for malicious-monitor log spam resistance.
> - Avoid adding __func__ to the new mon_client warnings.
> - Add a blank line between the front_len and data_len checks.
>
> v2:
> - Resend as an inline plain-text patch.
> - Add full email address to the From and Signed-off-by identities.
> - Add ceph-devel and LKML to the recipient list when sending.
>
> fs/ceph/mds_client.c | 16 ++++++++++++++++
> net/ceph/mon_client.c | 24 +++++++++++++++++++++++-
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
> index ed17e0023705e6d4e387ff7e5bd7fb53efdbaeb7..c84d12384717bbcaad369f353b00ccb8a7f2fcb0 100644
> --- a/fs/ceph/mds_client.c
> +++ b/fs/ceph/mds_client.c
> @@ -6543,13 +6543,19 @@ static int mds_handle_auth_bad_method(struct ceph_connection *con,
> static struct ceph_msg *mds_alloc_msg(struct ceph_connection *con,
> struct ceph_msg_header *hdr, int *skip)
> {
> + struct ceph_mds_session *s;
> + struct ceph_client *cl;
> struct ceph_msg *msg;
> int type = (int) le16_to_cpu(hdr->type);
> int front_len = (int) le32_to_cpu(hdr->front_len);
> + u32 data_len = le32_to_cpu(hdr->data_len);
>
> if (con->in_msg)
> return con->in_msg;
>
> + s = con->private;
> + cl = s->s_mdsc->fsc->client;
> +
> *skip = 0;
> msg = ceph_msg_new(type, front_len, GFP_NOFS, false);
> if (!msg) {
> @@ -6558,6 +6564,16 @@ static struct ceph_msg *mds_alloc_msg(struct ceph_connection *con,
> return NULL;
> }
>
> + if (data_len > msg->data_length) {
> + pr_warn_ratelimited_client(cl,
> + "mds%d message data %u > prealloc %zu, skipping\n",
> + s->s_mds, data_len,
> + msg->data_length);
> + ceph_msg_put(msg);
> + *skip = 1;
> + return NULL;
> + }
> +
> return msg;
> }
>
> diff --git a/net/ceph/mon_client.c b/net/ceph/mon_client.c
> index d2cdc8ee31551eb99ad062f191ac3cf984970130..66c0d6d6b33d37a25141117845b0f804664540ef 100644
> --- a/net/ceph/mon_client.c
> +++ b/net/ceph/mon_client.c
> @@ -712,6 +712,7 @@ static struct ceph_msg *get_generic_reply(struct ceph_connection *con,
> struct ceph_mon_client *monc = con->private;
> struct ceph_mon_generic_request *req;
> u64 tid = le64_to_cpu(hdr->tid);
> + u32 data_len = le32_to_cpu(hdr->data_len);
> struct ceph_msg *m;
>
> mutex_lock(&monc->mutex);
> @@ -720,6 +721,11 @@ static struct ceph_msg *get_generic_reply(struct ceph_connection *con,
> dout("get_generic_reply %lld dne\n", tid);
> *skip = 1;
> m = NULL;
> + } else if (data_len > req->reply->data_length) {
> + pr_warn_ratelimited("mon generic reply tid %llu data %u > preallocated %zu, skipping\n",
> + tid, data_len, req->reply->data_length);
> + *skip = 1;
> + m = NULL;
> } else {
> dout("get_generic_reply %lld got %p\n", tid, req->reply);
> *skip = 0;
> @@ -1499,6 +1505,7 @@ static struct ceph_msg *mon_alloc_msg(struct ceph_connection *con,
> struct ceph_mon_client *monc = con->private;
> int type = le16_to_cpu(hdr->type);
> int front_len = le32_to_cpu(hdr->front_len);
> + u32 data_len = le32_to_cpu(hdr->data_len);
> struct ceph_msg *m = NULL;
>
> *skip = 0;
> @@ -1536,13 +1543,28 @@ static struct ceph_msg *mon_alloc_msg(struct ceph_connection *con,
> if (!m) {
> pr_info("alloc_msg unknown type %d\n", type);
> *skip = 1;
> - } else if (front_len > m->front_alloc_len) {
> + return m;
> + }
> +
> + if (front_len > m->front_alloc_len) {
> pr_warn("mon_alloc_msg front %d > prealloc %d (%u#%llu)\n",
> front_len, m->front_alloc_len,
> (unsigned int)con->peer_name.type,
> le64_to_cpu(con->peer_name.num));
> ceph_msg_put(m);
> m = ceph_msg_new(type, front_len, GFP_NOFS, false);
> + if (!m)
> + return m;
> + }
> +
> + if (data_len > m->data_length) {
> + pr_warn_ratelimited("mon message data %u > prealloc %zu (%u#%llu), skipping\n",
> + data_len, m->data_length,
> + (unsigned int)con->peer_name.type,
> + le64_to_cpu(con->peer_name.num));
> + ceph_msg_put(m);
> + m = NULL;
> + *skip = 1;
> }
>
> return m;
Looks good.
Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Let me run xfstests suite for the patch. I'll be back with the results ASAP.
Thanks,
Slava.
next prev parent reply other threads:[~2026-05-08 18:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 19:37 [PATCH v2] libceph: reject monitor replies with oversized data segment Dhiraj Mishra
2026-05-01 21:37 ` Viacheslav Dubeyko
2026-05-02 5:22 ` [PATCH v3] " Dhiraj Mishra
2026-05-04 8:34 ` Raphael Zimmer
2026-05-04 9:16 ` [PATCH v4] libceph, ceph: reject oversized mon and MDS data segments Dhiraj Mishra
2026-05-04 19:46 ` Viacheslav Dubeyko
[not found] ` <CAG8b5tTiRK3AfTRx0hLeTi5GLfQ6sxXxfgUT+xzEqgzzDUMtOg@mail.gmail.com>
2026-05-05 18:48 ` Viacheslav Dubeyko
[not found] ` <CAG8b5tSigSQY4meBi24bYxYGrNsM1A4EAihh=gV0t0M1BCcYSg@mail.gmail.com>
2026-05-06 18:35 ` Viacheslav Dubeyko
2026-05-07 19:19 ` [PATCH v5] " Dhiraj Mishra
2026-05-08 18:18 ` Viacheslav Dubeyko [this message]
2026-05-11 16:24 ` Viacheslav Dubeyko
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=46a34e693aa1ba1e06108a80f5a14da320c7c284.camel@ibm.com \
--to=slava.dubeyko@ibm.com \
--cc=amarkuze@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=idryomov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mishra.dhiraj95@gmail.com \
--cc=raphael.zimmer@tu-ilmenau.de \
--cc=security@kernel.org \
--cc=slava@dubeyko.com \
--cc=w@1wt.eu \
/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
all inboxes | Powered by JetHome®