[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lsq.1576543535.45963212@decadent.org.uk>
Date: Tue, 17 Dec 2019 00:46:56 +0000
From: Ben Hutchings <ben@...adent.org.uk>
To: linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC: akpm@...ux-foundation.org, Denis Kirjanov <kda@...ux-powerpc.org>,
"Aurelien Aptel" <aaptel@...e.com>,
"Ronnie Sahlberg" <lsahlber@...hat.com>,
"Roberto Bergantinos Corpas" <rbergant@...hat.com>,
"Steve French" <stfrench@...rosoft.com>
Subject: [PATCH 3.16 082/136] CIFS: avoid using MID 0xFFFF
3.16.80-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Roberto Bergantinos Corpas <rbergant@...hat.com>
commit 03d9a9fe3f3aec508e485dd3dcfa1e99933b4bdb upstream.
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@...hat.com>
Reviewed-by: Ronnie Sahlberg <lsahlber@...hat.com>
Reviewed-by: Aurelien Aptel <aaptel@...e.com>
Signed-off-by: Steve French <stfrench@...rosoft.com>
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
fs/cifs/smb1ops.c | 3 +++
1 file changed, 3 insertions(+)
--- a/fs/cifs/smb1ops.c
+++ b/fs/cifs/smb1ops.c
@@ -180,6 +180,9 @@ cifs_get_next_mid(struct TCP_Server_Info
/* 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.
Powered by blists - more mailing lists