summaryrefslogtreecommitdiff
path: root/fs/smb/client/connect.c
diff options
context:
space:
mode:
authorSteve French <stfrench@microsoft.com>2023-08-25 07:29:18 +0300
committerSteve French <stfrench@microsoft.com>2023-08-25 07:37:06 +0300
commit09ee7a3bf866c0fa5ee1914d2c65958559eb5b4c (patch)
tree28032714614a3bbbe83a8b948d5def6164ad81cd /fs/smb/client/connect.c
parentb6d44d42313baa45a81ce9b299aeee2ccf3d0ee1 (diff)
downloadlinux-09ee7a3bf866c0fa5ee1914d2c65958559eb5b4c.tar.xz
[SMB3] send channel sequence number in SMB3 requests after reconnects
The ChannelSequence field in the SMB3 header is supposed to be increased after reconnect to allow the server to distinguish requests from before and after the reconnect. We had always been setting it to zero. There are cases where incrementing ChannelSequence on requests after network reconnects can reduce the chance of data corruptions. See MS-SMB2 3.2.4.1 and 3.2.7.1 Signed-off-by: Steve French <stfrench@microsoft.com> Cc: stable@vger.kernel.org # 5.16+
Diffstat (limited to 'fs/smb/client/connect.c')
-rw-r--r--fs/smb/client/connect.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/fs/smb/client/connect.c b/fs/smb/client/connect.c
index e19a9c81a5fa..f2d08d0f9373 100644
--- a/fs/smb/client/connect.c
+++ b/fs/smb/client/connect.c
@@ -1686,6 +1686,7 @@ cifs_get_tcp_session(struct smb3_fs_context *ctx,
ctx->target_rfc1001_name, RFC1001_NAME_LEN_WITH_NULL);
tcp_ses->session_estab = false;
tcp_ses->sequence_number = 0;
+ tcp_ses->channel_sequence_num = 0; /* only tracked for primary channel */
tcp_ses->reconnect_instance = 1;
tcp_ses->lstrp = jiffies;
tcp_ses->compress_algorithm = cpu_to_le16(ctx->compression);