[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120217005536.644510427@linuxfoundation.org>
Date: Thu, 16 Feb 2012 16:55:53 -0800
From: Greg KH <gregkh@...uxfoundation.org>
To: linux-kernel@...r.kernel.org, stable@...r.kernel.org
Cc: torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
alan@...rguk.ukuu.org.uk, Jeff Layton <jlayton@...hat.com>,
Steve French <smfrench@...il.com>
Subject: [19/28] cifs: dont return error from standard_receive3 after
marking response malformed
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Layton <jlayton@...hat.com>
commit ff4fa4a25a33f92b5653bb43add0c63bea98d464 upstream.
standard_receive3 will check the validity of the response from the
server (via checkSMB). It'll pass the result of that check to handle_mid
which will dequeue it and mark it with a status of
MID_RESPONSE_MALFORMED if checkSMB returned an error. At that point,
standard_receive3 will also return an error, which will make the
demultiplex thread skip doing the callback for the mid.
This is wrong -- if we were able to identify the request and the
response is marked malformed, then we want the demultiplex thread to do
the callback. Fix this by making standard_receive3 return 0 in this
situation.
Reported-and-Tested-by: Mark Moseley <moseleymark@...il.com>
Signed-off-by: Jeff Layton <jlayton@...hat.com>
Signed-off-by: Steve French <smfrench@...il.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
fs/cifs/connect.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -756,10 +756,11 @@ standard_receive3(struct TCP_Server_Info
cifs_dump_mem("Bad SMB: ", buf,
min_t(unsigned int, server->total_read, 48));
- if (mid)
- handle_mid(mid, server, smb_buffer, length);
+ if (!mid)
+ return length;
- return length;
+ handle_mid(mid, server, smb_buffer, length);
+ return 0;
}
static int
--
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/
Powered by blists - more mailing lists