From nobody Mon Jun 8 05:25:26 2026 Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D732B3603F8 for ; Tue, 2 Jun 2026 22:05:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780437924; cv=none; b=SJ4u9m1nzMo2qQZiT0+46/DEtbNN/a+Du/Qg523NAaGY0vPnLIakSAO4xjq7XrSLrdTnDpNjyHSWZTJBfy2lukQ43i7IjmELp/hlt70bCmYJZBrEhUFxRhY5DCJyvwJsN17oQP6Fr1TryeivG1Fo6CHI6UkX9xMUomqIz8MlW3M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780437924; c=relaxed/simple; bh=XC0KcaNw7SDbvUWq1bVjwUuRSHFM10TeVlcpU63KBBY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=VznL8Xi+CzdH3U2Xvl7KHJ2j2AqJmpmHst0E72of3FWlxylZRbOfJ8CFd71vb+kvq+HZgGSJzu2wAMuuzDkOnl5L8FxfKomLdq8/WnjO42JuPJ3gILm7cFuAg49eshr44/VrQ9VKtFFq3iJshb51rhuXvtI59xRMrH91DSGlw1s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Cg3+yDVc; arc=none smtp.client-ip=209.85.219.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Cg3+yDVc" Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-8cceb2ecc03so31701446d6.3 for ; Tue, 02 Jun 2026 15:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780437919; x=1781042719; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=iOc/r8laH9Q5rcV75Dpu9RWLNtUdzZsvgQiYjPZO9Lo=; b=Cg3+yDVcsU3UFOt5poogMKMOikHzJmoDrq4QcM2v3R8cjQH6Q78AuInUP8CKJOd3Q+ mdCL5ib9B2i0xtsDLLJXSvdRBkr36gmM2RmzWeCl5hhQpP+yQaXEu1bv2sIp9vDGzjUj nKFqvU8vxOu2bOlscGNjbTtp0VpTTBiJyYdgGruav9Lg/0s8Edq3F3I4ECCfe1iKsIcf Wtsq3lHz3vhRLn30n6uxmCxYnNxEP23chnemkYzFz/oshj5MZI2QHftIVyjJiVlnOtyz 3Fd2OyaWtBs8zH80T3Ny6jjQvFHX772ludmQXOhaPW1xI1ffdBx/0klk8JezlvUTMG/d tr/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780437919; x=1781042719; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=iOc/r8laH9Q5rcV75Dpu9RWLNtUdzZsvgQiYjPZO9Lo=; b=aa+2ERK3QX0CVKe22eOIbhEGR+kpjKFOTCBKQmlXIV8y1ey/6nEc5tUI7+1DAsBL4d pE0TLO8xaHyllXwYnbYmd3676GXUJ9DyzQz4uhkAroqmVnp48yH7bsE69xnwSeIrX59/ fFa8jiRrM2Hc40ZnFYqdAFa13PlP6HUK/TqnvTlOtNPXXaAL7mRCMkd2EYGDgyIHCof2 6vm2iUehkzJdhDaeyAMPTvM2a9+EbleOqLhoDbdRfvRFRh5LEIE/IbZJmFLp1vuGdqV+ uZVzjUXs/phLOKfQ7dB5TygTS5HPMSBJKQIcpJ+A5UM35p09rFTNuOsnID/uu3rCM9Eh 5t3A== X-Forwarded-Encrypted: i=1; AFNElJ+Kj3L6j46EhZtZwsZxVJOMeS8+C4uoZ3sMzp2zkWmnkUsdhlRSgqzBnmEMDRPBk6P9QesCaRkvPW1sTss=@vger.kernel.org X-Gm-Message-State: AOJu0YzEi4bMw5+Hctgm6XSNwgRYLyYhMFFo/d6uxllirbzhjBINBFKE k0hEPlUAkLiYzzxioNzwg5kySn8ctKmzB41PbiZAcO5ksM74NpKsA3pj X-Gm-Gg: Acq92OGe4jJNx0KZbGnaL2Z3i0FPDTOoL9xFhrO98cwWxrD9YiYlYFwohj6c7Z2V93W 1oNc1OvJkrCBVm6tGGmIe/iGC/e3l02HGyxUyUFZFYbjbCHqFFva2HHduB1UvX1xdIrmth2ZHoe BuyCD4zcOjbaNrMYijGZtgPLcQUuSW+zRhRiuVdLPj6SvheBByj0oP0Ms/Oi2wroBDxgBT4hl4o j95YFuiQznlGu4QgYRStEVEZKHk1zDyHUeM5z24YSwcLLNelnx8eJZ03cu/vYEh20Wj7LNkgbYK gbCODIanK7LDY1NVuo8/txS9gIX5kZfqlgKLy1Ig1B0ed4fJ9HRcOQmQBH5+ftCwWjTlrZ0jnGx n3N/tTFjB0dWYrifzsBayMrf2Asa5GosNpCw2XTt76eXOY2106eKybep97fsGmdd65HuvZ/VDmi LrFqMAeQQBZoW3BuJg1l+x6Fs4NC/YK1W/o/2sYf6kaWrVLtT9vaobxoPs+wV//bWcwEIUBJNY/ JFdvb9O2YGeHTlEDBUdJSBytr6O1ck= X-Received: by 2002:a05:6214:4905:b0:8cc:f30b:642c with SMTP id 6a1803df08f44-8cecdd243dcmr7627236d6.43.1780437918693; Tue, 02 Jun 2026 15:05:18 -0700 (PDT) Received: from server0 (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8cecd077be8sm3480026d6.40.2026.06.02.15.05.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 15:05:18 -0700 (PDT) From: Michael Bommarito To: Bart Van Assche , Jason Gunthorpe , Leon Romanovsky Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] RDMA/srp: bound SRP_RSP sense copy by the received length Date: Tue, 2 Jun 2026 18:04:57 -0400 Message-ID: <20260602220457.2542840-1-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them. Fixes: aef9ec39c40c ("IB: Add SCSI RDMA Protocol (SRP) initiator") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Bart Van Assche --- Impact: a malicious or compromised SRP target the initiator has logged into can trigger an out-of-bounds read in srp_process_rsp() by returning an SRP_RSP with SRP_RSP_FLAG_SNSVALID and a large resp_data_len, faulting the initiator's SRP completion path. Changes since v1 (all per Bart Van Assche's review): - Commit message: state that the sense copy is bounded to SCSI_SENSE_BUFFERSIZE; the unbounded value is the source offset, not the number of bytes copied. - Describe the dropped case as truncated rather than oversized sense, in both the commit message and the log message. - Guard on the full sense_data_len so the truncated-sense log message is accurate; the copy stays bounded to SCSI_SENSE_BUFFERSIZE. Link to v1: https://lore.kernel.org/all/20260602194619.2272486-1-michael.bo= mmarito@gmail.com/ drivers/infiniband/ulp/srp/ib_srp.c | 30 +++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/s= rp/ib_srp.c index b58868e1cf11c..42eee27e6b2a1 100644 --- a/drivers/infiniband/ulp/srp/ib_srp.c +++ b/drivers/infiniband/ulp/srp/ib_srp.c @@ -1932,7 +1932,8 @@ static int srp_post_recv(struct srp_rdma_ch *ch, stru= ct srp_iu *iu) return ib_post_recv(ch->qp, &wr, NULL); } =20 -static void srp_process_rsp(struct srp_rdma_ch *ch, struct srp_rsp *rsp) +static void srp_process_rsp(struct srp_rdma_ch *ch, struct srp_rsp *rsp, + u32 byte_len) { struct srp_target_port *target =3D ch->target; struct srp_request *req; @@ -1973,10 +1974,27 @@ static void srp_process_rsp(struct srp_rdma_ch *ch,= struct srp_rsp *rsp) scmnd->result =3D rsp->status; =20 if (rsp->flags & SRP_RSP_FLAG_SNSVALID) { - memcpy(scmnd->sense_buffer, rsp->data + - be32_to_cpu(rsp->resp_data_len), - min_t(int, be32_to_cpu(rsp->sense_data_len), - SCSI_SENSE_BUFFERSIZE)); + u32 resp_len =3D be32_to_cpu(rsp->resp_data_len); + u32 sense_len =3D be32_to_cpu(rsp->sense_data_len); + + /* + * The sense data starts resp_data_len bytes past the + * response data area; both lengths come from the + * target-controlled response. Copy the sense data + * only if it has not been truncated, that is, only if + * the full sense region fits within the bytes actually + * received. Otherwise the copy source would run past + * the receive buffer (sized to the target-chosen + * max_ti_iu_len), reading out of bounds. + */ + if (sizeof(*rsp) + (u64)resp_len + sense_len <=3D byte_len) + memcpy(scmnd->sense_buffer, rsp->data + resp_len, + min_t(u32, sense_len, + SCSI_SENSE_BUFFERSIZE)); + else + shost_printk(KERN_ERR, target->scsi_host, + "dropping truncated sense data (resp_data_len %u sense_data_len = %u, %u bytes received)\n", + resp_len, sense_len, byte_len); } =20 if (unlikely(rsp->flags & SRP_RSP_FLAG_DIUNDER)) @@ -2086,7 +2104,7 @@ static void srp_recv_done(struct ib_cq *cq, struct ib= _wc *wc) =20 switch (opcode) { case SRP_RSP: - srp_process_rsp(ch, iu->buf); + srp_process_rsp(ch, iu->buf, wc->byte_len); break; =20 case SRP_CRED_REQ: --=20 2.53.0