recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an
outstanding read request. The peer-supplied payload length reaches it as
the signed int data_size, and two peer-controlled inputs can make it
negative. With a negotiated data-integrity-alg the digest length is
subtracted first, so a reply whose payload is smaller than the digest
underflows data_size. With no integrity algorithm (the default) data_size
is assigned from the unsigned h95/h100 wire length and drbdd() never
bounds it for a payload-carrying command, so a length above INT_MAX casts
it negative; this path needs no non-default feature. The bio receive loop
then computes expect = min_t(int, data_size, bv_len), which is negative,
and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX
into the first mapped page.

The sibling receive path read_in_block() is not affected: it uses an
unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving.
Reject a data reply whose size is negative after the optional digest
subtraction, covering both triggers.

Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen
bytes past a bio page in the receiver, corrupting kernel memory. A node
that reads from its peer (a diskless node, or read-balancing to the peer)
is exposed in the default configuration; data-integrity-alg is not
required.

Fixes: b411b3637fa7 ("The DRBD driver")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5-5-xhigh
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito <redacted>
---
Notes:

 - Reproduced on mainline f5459048c38a in a virtme-ng KASAN guest driving
   the real receiver over a loopback DRBD 8.4 connection with a
   man-in-the-middle proxy. Both triggers were confirmed before/after:
   (1) with data-integrity-alg=sha256, a P_DATA_REPLY one byte shorter
   than the digest; (2) with NO integrity algorithm (default), a
   P_DATA_REPLY whose h100 length is rewritten above INT_MAX. Stock
   panics with "KASAN: use-after-free in _copy_to_iter" from
   receive_DataReply (data_size seen as -1 and -1073741848 respectively);
   the patched build rejects both with -EIO and no KASAN. A benign read
   control (unmodified replies up to 128 KiB) passes on both stock and
   patched. The harness is available on request.
 - The sibling receive path read_in_block() is not affected: it uses an
   unsigned size and rejects it against DRBD_MAX_BIO_SIZE before
   receiving.
 - The pending "drbd: rework receiver for DRBD 9 transport and
   multi-peer protocol" series keeps the same unguarded subtraction and
   signed size in recv_dless_read(), so this check needs to be carried
   there too.

 drivers/block/drbd/drbd_receiver.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/block/drbd/drbd_receiver.c b/drivers/block/drbd/drbd_receiver.c
index 58b95bf4bdca6..2135c14354a85 100644
--- a/drivers/block/drbd/drbd_receiver.c
+++ b/drivers/block/drbd/drbd_receiver.c

@@ -1810,6 +1810,11 @@ static int recv_dless_read(struct drbd_peer_device *peer_device, struct drbd_req
 		data_size -= digest_size;
 	}
 
+	if (data_size < 0) {
+		drbd_err(peer_device, "Invalid data reply size\n");
+		return -EIO;
+	}
+
 	/* optimistically update recv_cnt.  if receiving fails below,
 	 * we disconnect anyways, and counters will be reset. */
 	peer_device->device->recv_cnt += data_size>>9;

-- 
2.53.0