linux-kernel - [65/89] cifs: dont allow cifs_reconnect to exit with NULL socket

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Jun 2011 17:00:28 -0700
From:	Greg KH <gregkh@...e.de>
To:	linux-kernel@...r.kernel.org, stable@...nel.org
Cc:	stable-review@...nel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	Jeff Layton <jlayton@...hat.com>,
	Steve French <sfrench@...ibm.com>
Subject: [65/89] cifs: dont allow cifs_reconnect to exit with NULL socket

2.6.39-stable review patch.  If anyone has any objections, please let us know.

------------------
 pointer

From: Jeff Layton <jlayton@...hat.com>

commit 7fdbaa1b8daa1009b705985b903e3d2ebccad456 upstream.

It's possible for the following set of events to happen:

cifsd calls cifs_reconnect which reconnects the socket. A userspace
process then calls cifs_negotiate_protocol to handle the NEGOTIATE and
gets a reply. But, while processing the reply, cifsd calls
cifs_reconnect again.  Eventually the GlobalMid_Lock is dropped and the
reply from the earlier NEGOTIATE completes and the tcpStatus is set to
CifsGood. cifs_reconnect then goes through and closes the socket and sets the
pointer to zero, but because the status is now CifsGood, the new socket
is not created and cifs_reconnect exits with the socket pointer set to
NULL.

Fix this by only setting the tcpStatus to CifsGood if the tcpStatus is
CifsNeedNegotiate, and by making sure that generic_ip_connect is always
called at least once in cifs_reconnect.

Note that this is not a perfect fix for this issue. It's still possible
that the NEGOTIATE reply is handled after the socket has been closed and
reconnected. In that case, the socket state will look correct but it no
NEGOTIATE was performed on it be for the wrong socket. In that situation
though the server should just shut down the socket on the next attempted
send, rather than causing the oops that occurs today.

Reported-and-Tested-by: Ben Greear <greearb@...delatech.com>
Signed-off-by: Jeff Layton <jlayton@...hat.com>
Signed-off-by: Steve French <sfrench@...ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>

---
 fs/cifs/connect.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -199,7 +199,7 @@ cifs_reconnect(struct TCP_Server_Info *s
 	}
 	spin_unlock(&GlobalMid_Lock);

-	while (server->tcpStatus == CifsNeedReconnect) {
+	do {
 		try_to_freeze();

 		/* we should try only the port we connected to before */
@@ -214,7 +214,7 @@ cifs_reconnect(struct TCP_Server_Info *s
 				server->tcpStatus = CifsNeedNegotiate;
 			spin_unlock(&GlobalMid_Lock);
 		}
-	}
+	} while (server->tcpStatus == CifsNeedReconnect);

 	return rc;
 }
@@ -3208,7 +3208,7 @@ int cifs_negotiate_protocol(unsigned int
 	}
 	if (rc == 0) {
 		spin_lock(&GlobalMid_Lock);
-		if (server->tcpStatus != CifsExiting)
+		if (server->tcpStatus == CifsNeedNegotiate)
 			server->tcpStatus = CifsGood;
 		else
 			rc = -EHOSTDOWN;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/