CIFS: avoid using MID 0xFFFF
authorRoberto Bergantinos Corpas <rbergant@redhat.com>
Mon, 14 Oct 2019 08:59:23 +0000 (10:59 +0200)
committerSteve French <stfrench@microsoft.com>
Mon, 21 Oct 2019 00:19:49 +0000 (19:19 -0500)
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>
fs/cifs/smb1ops.c

index b7421a0963195137474d9e3a15075796743c6157..514810694c0f5a7b48bfa6139401beb8c40c68cf 100644 (file)
@@ -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.