summaryrefslogtreecommitdiffstats
path: root/fs/cifs/smb1ops.c
diff options
context:
space:
mode:
authorRoberto Bergantinos Corpas <rbergant@redhat.com>2019-10-14 10:59:23 +0200
committerSteve French <stfrench@microsoft.com>2019-10-21 02:19:49 +0200
commit03d9a9fe3f3aec508e485dd3dcfa1e99933b4bdb (patch)
tree73bb8587830b41af04ab1e8d3824133cd003ee47 /fs/cifs/smb1ops.c
parentcifs: clarify comment about timestamp granularity for old servers (diff)
downloadlinux-03d9a9fe3f3aec508e485dd3dcfa1e99933b4bdb.tar.xz
linux-03d9a9fe3f3aec508e485dd3dcfa1e99933b4bdb.zip
CIFS: avoid using MID 0xFFFF
According to MS-CIFS specification MID 0xFFFF should not be used by the CIFS client, but we actually do. Besides, this has proven to cause races leading to oops between SendReceive2/cifs_demultiplex_thread. On SMB1, MID is a 2 byte value easy to reach in CurrentMid which may conflict with an oplock break notification request coming from server Signed-off-by: Roberto Bergantinos Corpas <rbergant@redhat.com> Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com> Reviewed-by: Aurelien Aptel <aaptel@suse.com> Signed-off-by: Steve French <stfrench@microsoft.com> CC: Stable <stable@vger.kernel.org>
Diffstat (limited to 'fs/cifs/smb1ops.c')
-rw-r--r--fs/cifs/smb1ops.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/fs/cifs/smb1ops.c b/fs/cifs/smb1ops.c
index b7421a096319..514810694c0f 100644
--- a/fs/cifs/smb1ops.c
+++ b/fs/cifs/smb1ops.c
@@ -171,6 +171,9 @@ cifs_get_next_mid(struct TCP_Server_Info *server)
/* we do not want to loop forever */
last_mid = cur_mid;
cur_mid++;
+ /* avoid 0xFFFF MID */
+ if (cur_mid == 0xffff)
+ cur_mid++;
/*
* This nested loop looks more expensive than it is.