mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Guanglei Zhu <zhugl3@xiaopeng.com>
To: Ilya Dryomov <idryomov@gmail.com>,
	Alex Markuze <amarkuze@redhat.com>,
	Viacheslav Dubeyko <slava@dubeyko.com>
Cc: ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: [PATCH 2/2] ceph: fix out-of-bounds read in ceph_netfs_issue_op_inline()
Date: Tue,  8 Sep 2026 14:21:19 +0800	[thread overview]
Message-ID: <20260908062119.402027-2-zhugl3@xiaopeng.com> (raw)
In-Reply-To: <20260908062119.402027-1-zhugl3@xiaopeng.com>

The read offset is validated against i_size but never against
inline_len, and the two fields come from the MDS independently.  When
a read starts past the end of the inline data, the subtraction

	len = min_t(size_t, iinfo->inline_len - subreq->start, subreq->len);

underflows and min_t() ends up with subreq->len, so copy_to_iter()
reads past the end of the inline buffer straight into the user
buffer.  A malicious or buggy MDS reporting a short inline payload
together with an inflated i_size can thus leak kernel heap memory to
userspace.

Bail out when the offset is not within the inline data.  The subreq
then completes short without progress and the read fails with
-ENODATA.

Fixes: 5b19f1eba459 ("ceph: make ceph_netfs_issue_op() handle inlined data")
Cc: stable@vger.kernel.org
Signed-off-by: Guanglei Zhu <zhugl3@xiaopeng.com>
---

Verified with a fault injector on the reply decoding path that
makes the MDS report a short inline payload with an inflated i_size:
the unpatched client trips HARDENED_USERCOPY on a read past the end
of the reply buffer, with the check the read fails with -ENODATA.
 fs/ceph/addr.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
index 795cd1b9e..0db807abc 100644
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -322,6 +322,11 @@ static bool ceph_netfs_issue_op_inline(struct netfs_io_subrequest *subreq)
 		return false;
 	}
 
+	if (subreq->start >= iinfo->inline_len) {
+		ceph_mdsc_put_request(req);
+		goto out;
+	}
+
 	len = min_t(size_t, iinfo->inline_len - subreq->start, subreq->len);
 	err = copy_to_iter(iinfo->inline_data + subreq->start, len, &subreq->io_iter);
 	if (err == 0) {
-- 
2.43.0


  reply	other threads:[~2026-09-08  6:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08  6:21 [PATCH 1/2] ceph: clamp the inline data length in ceph_fill_inline_data() Guanglei Zhu
2026-09-08  6:21 ` Guanglei Zhu [this message]
2026-09-10  3:00 ` [PATCH v2 " Guanglei Zhu
2026-09-10  3:00   ` [PATCH v2 2/2] ceph: fix out-of-bounds read in ceph_netfs_issue_op_inline() Guanglei Zhu

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=20260908062119.402027-2-zhugl3@xiaopeng.com \
    --to=zhugl3@xiaopeng.com \
    --cc=amarkuze@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=idryomov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=slava@dubeyko.com \
    --cc=stable@vger.kernel.org \
    /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®