[PATCH] libceph: bound sparse-read consumption to received data in secure mode

[Dairui Zhang <zhangdairui@gmail.com>]

In msgr2 secure mode the whole reply tail is read into a page vector
sized by the preamble-declared tail_len:

        enc_page_cnt = calc_pages_for(0, tail_len);

tail_len comes from the peer: preamble parsing only enforces
fd_lens[3] <= CEPH_MSG_MAX_DATA_LEN, and for sparse replies the
data_len sanity check is skipped entirely (osd_client.c:5458, gated
on !srlen).

process_v2_sparse_read() then walks that vector by server-supplied
extent lengths with no bounds check:

        int idx = spos >> PAGE_SHIFT;
        struct page *spage = con->v2.in_enc_pages[idx];

sparse_extent_map_valid() only requires the extents to be ordered,
non-overlapping, inside the *requested* range, sum(len) ==
sr_datalen, and each len <= INT_MAX. So an OSD can send a tiny tail
with a perfectly valid extent map claiming data that was never sent,
and nothing notices. (The destination cursor doesn't clamp this
either: sparse_read_total is the sum of the *request's* op lengths,
and the map validation forces sum(len) <= sr_req_len, so the
destination can't run out before the source overruns.)

With a malicious or compromised OSD - the same model as
CVE-2026-89657 - the copy loop runs off the end of the page vector:

  - past in_enc_page_cnt, adjacent slab gets dereferenced as struct
    page * -> near-certain oops;
  - even before that, ceph_alloc_page_vector() doesn't zero its
    pages, so the tail-page slack is stale kernel memory that gets
    memcpy_page()d into the user's read() buffer every time;
  - if a wild page * happens to be dereferenceable, adjacent heap
    keeps flowing into read() too.

Plain (crc) mode doesn't have the problem - it pulls from the socket
on demand and bails with -EIO past cursor->total_resid.

Trigger: cephfs with ms_mode=secure, sparse path taken via the
sparseread mount option or fscrypt-encrypted inodes
(fs/ceph/file.c:1079,1541). I didn't check whether rbd issues
SPARSE_READ, so no claim there.

This isn't CVE-2026-89657: that one validated the map against the
request range to avoid the BUG_ON, it doesn't cover the secure-mode
supply/consumption mismatch. Unchanged in mainline as of today.

Reject consumption beyond the received data. Guarding idx covers
both the metadata and the data copies.

Fixes: f36217e35ce1 ("libceph: support sparse reads on msgr2 secure codepath")
Signed-off-by: Dairui Zhang <zhangdairui@gmail.com>
---
First time posting to ceph-devel, and this is from code reading
rather than a live cluster - if I've misread the messenger flow or
the guard belongs somewhere else, please say so and I'll respin.

 net/ceph/messenger_v2.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/ceph/messenger_v2.c b/net/ceph/messenger_v2.c
index b323b61..c677ff8 100644
--- a/net/ceph/messenger_v2.c
+++ b/net/ceph/messenger_v2.c
@@ -1077,6 +1077,10 @@ static int process_v2_sparse_read(struct ceph_connection *con,
 		do {
 			int idx = spos >> PAGE_SHIFT;
 			int soff = offset_in_page(spos);
+
+			if (idx >= con->v2.in_enc_page_cnt)
+				return -EREMOTEIO;
+
 			struct page *spage = con->v2.in_enc_pages[idx];
 			int len = min_t(int, ret, PAGE_SIZE - soff);

If there's interest I'll follow up with two small patches: zeroing
pages in ceph_alloc_page_vector() (closes the stale-page leak), and
a KUnit case that feeds a short tail plus a large extent map into
process_v2_sparse_read().