From nobody Mon May 25 08:11:40 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 34716317143 for ; Fri, 15 May 2026 19:31:49 +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=1778873510; cv=none; b=FpZOuhdUomOWlpuNGOCyXPqLfIpu0Sw86xn7t08rzbsMM2pxnteYcHIhclt3nx1X2SuHLgmzS0WlIjPzQ3sjK8W95hjKRY9hA0eWnmvO04nrziJ22442ZR48LGjj0opwun/F5XZKpJSrf9rJsceNlQzKlqnc0CbVAiBT8/ZCxv4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778873510; c=relaxed/simple; bh=x30wO2FhwyPK4fF9T73E7uFT/ppNy/M8P5Pz9ayv+14=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Bl81dEuWa7Ntoi5hiGuKkQg9KXp3/1RnEua3MyDWXWio1bhscwo5iNkb99f6aCNeIuYaHFkvmCqwhb80Zxchj1MXM39BOLMQWxRDc9Rfr2lWxewZTlN/8F5RfPwUH3gtto4hc0Aol0nyXdMlk9mNjPaNG+INauCNCY79hswUDPI= 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=ftTQzxtN; 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="ftTQzxtN" Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-8b821f39a12so1713896d6.2 for ; Fri, 15 May 2026 12:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778873508; x=1779478308; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=pZwZ1sbOq1osboJiviKs99QuPcaN2fyHvMmUqI3TItE=; b=ftTQzxtNhbz68/DMbVReybKdWSczG09d+ZHS2Jdz7BnquKEWOnTZgeQZmGbWs3ov+J gi0nlASZezNqijmB19KT4lTKUBqrQVZDVPtGnKF5cu8CdMvQLTHoGaJvGVJ6doZ0+UVv 8mW7WOFeE6vuD0BBkkeGJrl4UcBlUdzvZ8LPU+BtG80VwBz1We44X+vbfwApvtLRi8p4 xn9Z1BLjAG3dJVviKF78DwKeLczHIFYzVug0g2Z7NIizZ1mJen6m2UE6AgSpLkuKyGa4 t9xKXdq/3vetsyloabj+Na8oldo39KANEQb2YIbOPC7yq/dvKUt4oqXx/gGw58Hxid+Y m1vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778873508; x=1779478308; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=pZwZ1sbOq1osboJiviKs99QuPcaN2fyHvMmUqI3TItE=; b=PpLpGFMsROUtq26Sy4fDM8sXtYtyg7vxXcks2Vbw88WLnHQTtLASLPF31EqgJDtwnB Dne+w/NK6tPmumF3G9hNrpLOspZiasV86SuqDSl617LV9H1P+j02hMC4DBuiTC6XmDoK GVReZQIJ+8Y7x0IMFhuO4PwZnv5YOHLcVwZFrpWSg0G5AKce09iudinQCNxLXBohkGLx LZQ3guhhwp83ZFNq0JRWCDnXOUHCW9cWrpQwX24LJXGzqqA0BbaFgYxANwE4I+FhpLTO 6k7Hd/HYiXM6cpLNoYMJWwyCVN58ikLeW2pYxqdDc8y97Jn23o+rexYaSItwlZ2CXjz+ 3+nQ== X-Forwarded-Encrypted: i=1; AFNElJ+i11xFZJIMcJ3Avqy+G/bgyp51lKmgpCjcO4JgN0HZ+t+ZsWA+kHPcCtf3Z8HnkhMHjTjEWFUfbkrviiM=@vger.kernel.org X-Gm-Message-State: AOJu0YyI8d52TcyQt+Ysgq+mgG5ytmUXiUqHW4t3M6MAGgxD3zgUocP8 ELuAA07WBFaxU69GF+mOUl9DUK0SBNQ8FPttdAfmL/ga6VWm1+KV9++L X-Gm-Gg: Acq92OHEIrFKv0J0NdjHaZUq9ZID25jkbMBVO0pB1YwxHBR8exjqDaA6xXDFPi8lvLs lBlrU4JcOU7S0wraCrpmMABXFFE1o/4YmiikQ/tjVzofSGcbwZ5ZIjlPEK4EofkvUXqWVLh4FRE jJOk6eoGDgXEhSKlDv6c9+V2Bh5qHzbMVt6bkjPlRNscCVwcjnapxmWvG70/2x7FiEX1zVHtsUW 2CFgoNX8ORW2Y7OVoHbsgkbgCT5VEwLN7G/wxnNvNHoBfYQ/hiFSxa9HKp1ynOIkc7zgXeSStE8 kt7AcAP/BMZ2IiRU9C7Fb72v9CushcHltuvBqZlTr120Wo1pmbOSt3JcdqqRvpAX+RAIxpeNlqb uI9CPxvGtrBw271WFzxW7SLH2zra3oCTt8QM+F/MRDSmJl1eqZKaT32w22j5oS39BBYVKV5xD26 6Osq89KkbKCtJ2FuBjnDHuNycyI6PjH1p9dKWD+tx33g32c7UxOPK24JaAT8g1sQ9fhTnX/pdnS WnwOe0qUsSr8uk= X-Received: by 2002:a05:6214:2f8b:b0:8ca:10c9:845d with SMTP id 6a1803df08f44-8ca10c98663mr92214146d6.31.1778873508135; Fri, 15 May 2026 12:31:48 -0700 (PDT) Received: from jeremy.kali (srv1619992.hstgr.cloud. [2a02:4780:75:55a3::1]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8c90c165434sm60542846d6.43.2026.05.15.12.31.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2026 12:31:47 -0700 (PDT) From: Jeremy Erazo To: Steve French Cc: linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] smb: client: use data_len for SMB2 READ encrypted folioq copy Date: Fri, 15 May 2026 19:31:41 +0000 Message-ID: <20260515193141.542623-1-mendozayt13@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: 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 handle_read_data() the encrypted/folioq branch (buf_len <=3D data_offset, reached via receive_encrypted_read for transform PDUs > CIFSMaxBufSize + MAX_HEADER_SIZE) copies the READ payload using buffer_len rather than data_len: rdata->result =3D cifs_copy_folioq_to_iter(buffer, buffer_len, cur_off, &rdata->subreq.io_iter); ... rdata->got_bytes =3D buffer_len; buffer_len comes from the SMB3 transform header OriginalMessageSize field (OriginalMessageSize - read_rsp_size); it represents the size of the decrypted message after the SMB2 header. data_len comes from the SMB2 READ response DataLength field; it represents the actual READ payload size and may be smaller than buffer_len when the decrypted message contains padding or other trailing bytes after the READ payload. The existing check `data_len > buffer_len - pad_len` only enforces an upper bound, so a server that emits OriginalMessageSize larger than read_rsp_size + pad_len + data_len passes the check and the kernel copies buffer_len bytes per response, ignoring the server-asserted DataLength. Two observable failures with a crafted server (DataLength=3D4, buffer_len=3D20000): - the kernel returns 20000 bytes per sub-request to userspace and sets got_bytes =3D buffer_len, even though the response claimed only 4 bytes of payload; - on a partial netfs sub-request whose iterator is sized to data_len, the over-large copy_folio_to_iter() short-reads, cifs_copy_folioq_to_iter() returns -EIO via the n !=3D len path, and the entire netfs read collapses to -EIO even though the leading sub-requests succeeded. Use data_len for the copy length and for got_bytes so the kernel honours the server-asserted READ payload size. For well-formed servers (where buffer_len =3D=3D pad_len + data_len) the change is behaviour-equivalent. Signed-off-by: Jeremy Erazo --- fs/smb/client/smb2ops.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c --- a/fs/smb/client/smb2ops.c +++ b/fs/smb/client/smb2ops.c @@ -4825,7 +4825,7 @@ handle_read_data(struct TCP_Server_Info *server, stru= ct mid_q_entry *mid, } /* Copy the data to the output I/O iterator. */ - rdata->result =3D cifs_copy_folioq_to_iter(buffer, buffer_len, + rdata->result =3D cifs_copy_folioq_to_iter(buffer, data_len, cur_off, &rdata->subreq.io_iter); if (rdata->result !=3D 0) { if (is_offloaded) @@ -4834,5 +4834,5 @@ handle_read_data(struct TCP_Server_Info *server, stru= ct mid_q_entry *mid, dequeue_mid(server, mid, rdata->result); return 0; } - rdata->got_bytes =3D buffer_len; + rdata->got_bytes =3D data_len;