From nobody Fri Sep 25 21:41:35 2026 Received: from oss.cyber.gouv.fr (oss.cyber.gouv.fr [51.159.188.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C5EB14C6F02; Tue, 8 Sep 2026 08:57:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=51.159.188.251 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788857836; cv=none; b=tjqES2jRKDf/kX0oau8WknSVuJjxKAz1s5hyX/Xh2MnI6Ah4XIoiu/IwTNaRFvlrVQeTXEIeppBj/cxd1OHiL0w7S5vmS0l+cTjHUBETMyke2qH5/NfUqQf4PCmgjLJkQ2WmjtQtFUG3Vh7bhrYjrWsX8spyeysO5qXbb3zY5IY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788857836; c=relaxed/simple; bh=0WTp4jKOu7kXJpZWhF18gcUryoayh8GSWUx+zRwvlmM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=lmw7Cqx50NsTYVr0B91Y9hDU7ZhhuX4o8zYNvEKibnsyZ4C046ZlNJmlaLaPeDNUwdpX5mzS920gddLhCBVEOz5UQuk/hkfbDuuNTAek6aEXTm5UfiQ/H9kLNK7nYCpYbAN0GepKGZnAjhtZvGoHDvg2akLdSaFsEOsR7MJem2Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=oss.cyber.gouv.fr; spf=pass smtp.mailfrom=oss.cyber.gouv.fr; dkim=pass (2048-bit key) header.d=oss.cyber.gouv.fr header.i=@oss.cyber.gouv.fr header.b=rtrAoBe9; arc=none smtp.client-ip=51.159.188.251 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=oss.cyber.gouv.fr Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.cyber.gouv.fr Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oss.cyber.gouv.fr header.i=@oss.cyber.gouv.fr header.b="rtrAoBe9" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=oss.cyber.gouv.fr; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=5ORpgd9LZyUIy9zKWsX54UKRQl0NlLog2HKUq206CxE=; b=rtrAoBe9PSpmokfCcOWbx/MtrX tSD2Yrl3HZniF+1Q0G3WkxzAZ3/0Xm+DAIFqM11gXSBN2v32cwUXv8dBpLvXLgv6lsPWaF1k/8knj l/MHdWVaJRwrTn26FCwI+b10m9AOhPWZKkXuOGRCH1DZB65wLfzUOADJbNvwmBf7vesjjR6zRH4vj uJ5flK6UePA9SJH/R15tjKCZHep/A0vH4qPFy5W4+NrGEUxuoh3DUOWvDlzSoksMRutlRul4PYuZX QmBgdSvJytEFA9AcRbZ2LhvENtk6UqqlNS7+bKV28GBZpj0WovubOiYfAnJyL0Up0l1YAKh+9W4Yk UZ5LeReg==; Received: from [151.115.150.205] (port=38990 helo=gepetto..) by pf-012.whm.fr-par.scw.cloud with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.99.5) (envelope-from ) id 1x3rdQ-00000009Qlt-3XtX; Tue, 08 Sep 2026 10:56:55 +0200 From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Jean?= To: bernard.metzler@linux.dev Cc: jgg@nvidia.com, leonro@nvidia.com, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, =?UTF-8?q?J=C3=A9r=C3=A9my=20Jean?= Subject: [PATCH] RDMA/siw: Bound fragmented header copies by the remaining length Date: Tue, 8 Sep 2026 08:55:20 +0000 Message-ID: <20260908085520.1746329-1-Jeremy.Jean@oss.cyber.gouv.fr> X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - pf-012.whm.fr-par.scw.cloud X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - oss.cyber.gouv.fr X-Get-Message-Sender-Via: pf-012.whm.fr-par.scw.cloud: authenticated_id: jeremy.jean@oss.cyber.gouv.fr X-Authenticated-Sender: pf-012.whm.fr-par.scw.cloud: jeremy.jean@oss.cyber.gouv.fr X-Source: X-Source-Args: X-Source-Dir: siw_get_hdr() can receive an extended DDP/RDMAP header across more than one TCP callback. The first callback may receive most of the header, while the next one still limits the copy to hdrlen - MIN_DDP_HDR instead of the number of missing bytes. This makes the destination move past the end of the header and overwrite the receive state, including fpdu_part_rcvd. A later callback can then use a negative fpdu_part_rcvd value as a copy offset, which creates an OOB write. Use the number of header bytes already received when calculating the next copy length. Fixes: 754209850df8 ("RDMA/siw: Always consume all skbuf data in sk_data_re= ady() upcall.") Signed-off-by: J=C3=A9r=C3=A9my Jean Assisted-by: Codex:gpt-6 Acked-by: Bernard Metzler --- drivers/infiniband/sw/siw/siw_qp_rx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/sw/siw/siw_qp_rx.c b/drivers/infiniband/sw/= siw/siw_qp_rx.c index b566d16..e5b641c 100644 --- a/drivers/infiniband/sw/siw/siw_qp_rx.c +++ b/drivers/infiniband/sw/siw/siw_qp_rx.c @@ -1079,7 +1079,7 @@ static int siw_get_hdr(struct siw_rx_stream *srx) if (iwarp_pktinfo[opcode].hdr_len > sizeof(struct iwarp_ctrl_tagged)) { int hdrlen =3D iwarp_pktinfo[opcode].hdr_len; =20 - bytes =3D min_t(int, hdrlen - MIN_DDP_HDR, srx->skb_new); + bytes =3D min_t(int, hdrlen - srx->fpdu_part_rcvd, srx->skb_new); =20 skb_copy_bits(skb, srx->skb_offset, (char *)c_hdr + srx->fpdu_part_rcvd, bytes); --=20 2.47.3