Re: [SECURITY] ceph: msgr2 monitor data_len mismatch can trigger client kernel panic

[Willy Tarreau <w@1wt.eu>]

On Fri, May 01, 2026 at 11:11:44AM -0700, Viacheslav Dubeyko wrote:
> On Fri, 2026-05-01 at 21:53 +0400, Dhiraj Mishra wrote:
> > Sure noted, here is the patch.
> > 
> > From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00
> > 2001
> > From: Dhiraj Mishra
> > Date: Fri, 1 May 2026 12:45:00 +0400
> > Subject: [PATCH] libceph: reject monitor replies with oversized data
> > segment
> > 
> > Monitor messages can be allocated from preallocated reply messages or
> > with ceph_msg_new(), both of which may provide 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 monitor advertises a non-zero data
> > segment
> > for one of these front-only replies, 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 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 monitor allocator pattern is older, but
> > I
> > have not tested older msgr1-only kernels.
> > 
> > A concrete 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.
> > 
> > Reject monitor replies whose wire data segment is larger than the
> > data
> > backing allocated for the selected ceph_msg, mirroring the existing
> > OSD
> > reply hardening.
> > 
> > Signed-off-by: Dhiraj Mishra
> > ---
> >  net/ceph/mon_client.c | 21 +++++++++++++++++++++
> >  1 file changed, 21 insertions(+)
> > 
> > diff --git a/net/ceph/mon_client.c b/net/ceph/mon_client.c
> > index d2cdc8ee3155..7f2293122bba 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,16 @@ 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 (!req->reply) {
> > + pr_warn("%s tid %llu missing reply buffer, skipping\n",
> > + __func__, tid);
> > + *skip = 1;
> > + m = NULL;
> > + } else if (data_len > req->reply->data_length) {
> > + pr_warn("%s tid %llu data %u > preallocated %zu, skipping\n",
> > + __func__, 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 +1510,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;
> > @@ -1544,6 +1556,15 @@ static struct ceph_msg *mon_alloc_msg(struct
> > ceph_connection *con,
> >   ceph_msg_put(m);
> >   m = ceph_msg_new(type, front_len, GFP_NOFS, false);
> >   }
> > + if (m && data_len > m->data_length) {
> > + pr_warn("%s data %u > prealloc %zu (%u#%llu), skipping\n",
> > + __func__, 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;
> >  }
> 
> 
> I assume that the email has been sent not in plain text and
> ceph-devel@vger.kernel.org simply rejected the email. Could you please
> follow to the common practice of sending patches [1]?
> 
> Thanks,
> Slava.
> 
> [1] https://docs.kernel.org/process/submitting-patches.html

This one should help to fix your mail client's configuration:

   Documentation/process/email-clients.rst

Willy