From nobody Mon Jun 8 05:25:26 2026 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) (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 9E0A7244675 for ; Tue, 2 Jun 2026 19:46:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.169 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780429610; cv=none; b=g7iWFneWxIC7Hj5RFqHAKCq0NErgC/W7qy7hhK5mTtnBt8VDIqS7CrlHcgi3x5bKNs9dB+PRQCwXpAkkjLyTsB0jmwga7KVSF+P3RWn8g6KvU49W/uPelsXtZGp/15Is7a6AZdlEgbHNs7SQxgZOQY6iq/5WmQjf7QyRhXing/g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780429610; c=relaxed/simple; bh=D6UZDnyjlzb1tjCGRTyvdU0cKpyDRuOWJ7z+8lBC1rs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Pm43KkketC1eb9P73HgHAhCjf5yIRp0Vrw/uty8xm7t3D3w+n8CV3IJADYnwwq100dgGX8/hxq2iy6xhE/izSSUKVYv3mVerhLWNQBR+9zntD26agrul7dqVcJIAPbd0dDcr/moAvjPzo77cvlbY17w9l14jCismZR6tGKadTe4= 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=Cl90eKqR; arc=none smtp.client-ip=209.85.160.169 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="Cl90eKqR" Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-516de78c4dcso109644681cf.2 for ; Tue, 02 Jun 2026 12:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780429608; x=1781034408; 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=HZT0cZ8sVMgpqU3LQqdB6NvntMdy3q7IleXIHtXo8Wk=; b=Cl90eKqRJ2hhwSo6IFVI9UE3drHZjG5skEklbrMBSCsFqdjsHX6OSvdZWBST7ck2DQ srSkFJi/POfKBIyYXjWm6QwvxN0F+VZTOn4m3EVH9WMyEOJioIunXpSMDadqf0503Ecm Qp1zlFyy9fLY3mnZlq3XTojUZVmEmd1KE4DxKfWrouDaj6v2Mz4cXYkuwKww6VOqIZJ/ 905djg9WeD7GbvrQ8zO4i4/vEED1d24Fd/3IV40kp7mr9T3W9m1ZT4Ki+tenYT/QscOO Uwf9gOsSbfJkIxWsLV42WsG6rzw/nnRD7T7VvzLHbiHjS9dS5TcmoWmWDzDMVN8Mydry n30Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780429608; x=1781034408; 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=HZT0cZ8sVMgpqU3LQqdB6NvntMdy3q7IleXIHtXo8Wk=; b=oifCnFWrkaEqB+CKmfwD3a+aKpzAkSCTLTmcdHhClp8RAoInZPih3piUy6ARFf/k7F GkQIDPZFdsImKumCksMjB8LtZFWDuPPf+eoTH8/mcxR5a00BeYkQhSPy5eO17umaDmZK eBhvqtwqhmHD8iz47bZ4d4UVkJ67/jyH0jZ9qmdraYBWKFrwjzCLaaDO4vqrB1reKCKa 44C6UJycbQqacYgpMU/clmYy8zVTr8sWCzudLhRZeDKx82eOFdVl1FaoZ1pq06atYw11 whPJwbuTHJLipkImy+uJXGgecbyeKdHLn7+PAwFzX2d0aYxyQ3RB9iiJW+D3i7LkrQDQ ssFA== X-Forwarded-Encrypted: i=1; AFNElJ+FnVXF7YPzCDPyrE/FT/IptU9ZURb7Srekc1fCFQaYgCGWub59+KVxU2vGSBACUq4WnnT7LjgGtp4rr9E=@vger.kernel.org X-Gm-Message-State: AOJu0YypDpCnFA/3W3OyFN2KwRBBtgjsk9ACHbcaoJXkByeD/y64ioiu HWg/riwfCwqHiua54QWGyrCTFwn5j+SpNdCTv2KvjryxI1s/4rKk0IS2 X-Gm-Gg: Acq92OE3J56mmSZyZ3Mq5rSlWvbCPgVB+96PlDcxgmosjrbutd+1Op4Po1DVJFTmG1F OUi3RZUF3iAbtxwgjLnadJLk+Fj1EPnjn+dXzSG9zlIi/zYhashc0K7AQSoN7zhc+2wBqd+S65i BzWr83E5kTtVuSl5D6DA3lAGSKyJZpdH+7YwbKzKPotqlzHxF5XQxQBuC1rc8magFwh8dK6FKdV njhyZjBugj0kwC+0l1VX4QT53wMJD9cyKJlVV2HcI6kLv77V8j+lt6nv0HHFbgHI1D1JB3QpfhW QMkENouxkmyYFEJ4gkaaW5nv5zPRX6lEZ3ltbfGDrNCLEpNWcce2fKm70jxYgkqKM5IDo9HlhTe zf9NPQx2SxX5Rx3QnrUAoN7lzzOc0UEKb+K9kRZme4w7H2vjLZJsf1t2lAJZfnO235Rhdepjtxt vp1ftIHvKZ1ctGdE6lJncLYYc7+u72AhUlG8Pv0jEZvou7sO+bH/G1++AulLGTdblcfbWFdmQac PsAm/kgojjv2IPdlEtcaU+hONEXffM= X-Received: by 2002:a05:622a:1304:b0:517:64b8:5a1f with SMTP id d75a77b69052e-517786efdc8mr7448531cf.35.1780429607484; Tue, 02 Jun 2026 12:46:47 -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 d75a77b69052e-51775d8100fsm7136801cf.14.2026.06.02.12.46.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 12:46:46 -0700 (PDT) From: Michael Bommarito To: Sagi Grimberg , Jason Gunthorpe , Leon Romanovsky Cc: linux-rdma@vger.kernel.org, target-devel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] IB/isert: reject login PDUs shorter than ISER_HEADERS_LEN Date: Tue, 2 Jun 2026 15:46:42 -0400 Message-ID: <20260602194642.2273217-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" In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size =3D min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added. Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) tar= get driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito --- Impact: a remote, pre-auth iSER initiator can crash an iSER-enabled LIO target by sending a single login PDU shorter than ISER_HEADERS_LEN, underflowing login_req_len to a negative value that drives an out-of-bounds memcpy. Analysis =3D=3D=3D=3D=3D=3D=3D=3D Tree: mainline a1f173eb51db (7.1-rc4 line), x86_64. ISER_HEADERS_LEN is sizeof(struct iser_ctrl) (28, __packed) plus sizeof(struct iscsi_hdr) (48) =3D 76. login_req_len is a signed int (ib_isert.h). For a received login Send with wc->byte_len in 1..75, isert_login_recv_done() stores wc->byte_len - ISER_HEADERS_LEN, which underflows to a negative int. isert_rx_login_req() reads it back as int rx_buflen, computes size =3D min(rx_buflen, MAX_KEY_VALUE_PAIRS) (MAX_KEY_VALUE_PAIRS is 8192; the min is signed so size stays negative), and calls memcpy(login->req_buf, isert_get_data(rx_desc), size). login->req_buf is an 8192-byte kzalloc in the iSCSI target login path. The negative size sign-extends to a multi-gigabyte size_t at memcpy(), so the copy runs out of bounds of req_buf and faults. Conditions: an RDMA transport plus an iSER-enabled LIO target. iSER is enabled per portal (targetcli enable_iser); a plain iSCSI-over-TCP target does not load this path. RoCEv2 and iWARP transports are routable, so the initiator need not share the target's L2 segment; RoCEv1 and native InfiniBand require an adjacent initiator. The malformed login Send is accepted during the login phase, before iSCSI authentication, so no credentials are required. The upper bound is already safe: a posted login receive buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so wc->byte_len - 76 stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it. Only the missing lower bound is added here. The initiator-side iSER receive path rejects short receives; the target login path had no equivalent floor. With the patch, a login Send shorter than ISER_HEADERS_LEN is dropped in isert_login_recv_done() (the new early return logs "login request length N is too short") and login_req_len is left untouched, so the downstream min()/memcpy() length stays within the 8192-byte buffer; a well-formed login (wc->byte_len >=3D 76) is unaffected. The defect is identified by static analysis of the cited code paths; the path can be exercised by driving a short login Send at an rxe-backed iSER LIO target under KASAN. drivers/infiniband/ulp/isert/ib_isert.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/infiniband/ulp/isert/ib_isert.c b/drivers/infiniband/u= lp/isert/ib_isert.c index 348005e71891c..a849a420be421 100644 --- a/drivers/infiniband/ulp/isert/ib_isert.c +++ b/drivers/infiniband/ulp/isert/ib_isert.c @@ -1383,6 +1383,12 @@ isert_login_recv_done(struct ib_cq *cq, struct ib_wc= *wc) ib_dma_sync_single_for_cpu(ib_dev, isert_conn->login_desc->dma_addr, ISER_RX_SIZE, DMA_FROM_DEVICE); =20 + if (unlikely(wc->byte_len < ISER_HEADERS_LEN)) { + isert_err("login request length %u is too short\n", + wc->byte_len); + return; + } + isert_conn->login_req_len =3D wc->byte_len - ISER_HEADERS_LEN; =20 if (isert_conn->conn) { --=20 2.53.0