From 251a376c41ff4882d120c5b472e6d6080add975c Mon Sep 17 00:00:00 2001 From: Jeremy Allison Date: Tue, 22 Jan 2013 12:38:28 -0800 Subject: [PATCH 1/2] Revert "s3:smbd: SMB ReadX with size > 0xffff should only possible for samba clients." Part of fix for bug #9572 - File corruption during SMB1 read by Mac OSX 10.8.2 clients This reverts commit f8c26c16b82989e002b839fc9eba6386fc036f6a. --- source3/smbd/reply.c | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/source3/smbd/reply.c b/source3/smbd/reply.c index b511025..210b701 100644 --- a/source3/smbd/reply.c +++ b/source3/smbd/reply.c @@ -3854,7 +3854,6 @@ nosendfile_read: void reply_read_and_X(struct smb_request *req) { - struct smbd_server_connection *sconn = req->sconn; connection_struct *conn = req->conn; files_struct *fsp; off_t startpos; @@ -3893,15 +3892,7 @@ void reply_read_and_X(struct smb_request *req) return; } - if ((sconn->smb1.unix_info.client_cap_low & CIFS_UNIX_LARGE_READ_CAP) || - (get_remote_arch() == RA_SAMBA)) { - /* - * This is Samba only behavior (up to Samba 3.6)! - * - * Windows 2008 R2 ignores the upper_size, - * so we do unless unix extentions are active - * or "smbclient" is talking to us. - */ + if (global_client_caps & CAP_LARGE_READX) { size_t upper_size = SVAL(req->vwv+7, 0); smb_maxcnt |= (upper_size<<16); if (upper_size > 1) { -- 1.8.1 From 336e7582d09e18b4d0e4354e0271bf4675b80f44 Mon Sep 17 00:00:00 2001 From: Jeremy Allison Date: Wed, 23 Jan 2013 09:57:50 -0800 Subject: [PATCH 2/2] Fix bug #9572 - File corruption during SMB1 read by Mac OSX 10.8.2 clients. Accept a large read if we told the client we have UNIX extensions and the client sent a non-zero upper 16-bit size. Do the non-zero upper 16-bit size check first to save a function call in what is a hot path. Signed-off-by: Jeremy Allison --- source3/smbd/reply.c | 32 ++++++++++++++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/source3/smbd/reply.c b/source3/smbd/reply.c index 210b701..6e1cd27 100644 --- a/source3/smbd/reply.c +++ b/source3/smbd/reply.c @@ -3849,6 +3849,26 @@ nosendfile_read: } /**************************************************************************** + MacOSX clients send large reads without telling us they are going to do that. + Bug #9572 - File corruption during SMB1 read by Mac OSX 10.8.2 clients + Allow this if we are talking to a Samba client, or if we told the client + we supported this. +****************************************************************************/ + +static bool server_will_accept_large_read(void) +{ + /* Samba client ? No problem. */ + if (get_remote_arch() == RA_SAMBA) { + return true; + } + /* Need UNIX extensions. */ + if (!lp_unix_extensions()) { + return false; + } + return true; +} + +/**************************************************************************** Reply to a read and X. ****************************************************************************/ @@ -3858,6 +3878,7 @@ void reply_read_and_X(struct smb_request *req) files_struct *fsp; off_t startpos; size_t smb_maxcnt; + size_t upper_size; bool big_readX = False; #if 0 size_t smb_mincnt = SVAL(req->vwv+6, 0); @@ -3892,8 +3913,15 @@ void reply_read_and_X(struct smb_request *req) return; } - if (global_client_caps & CAP_LARGE_READX) { - size_t upper_size = SVAL(req->vwv+7, 0); + upper_size = SVAL(req->vwv+7, 0); + if ((upper_size != 0) && server_will_accept_large_read()) { + /* + * This is Samba only behavior (up to Samba 3.6)! + * + * Windows 2008 R2 ignores the upper_size, + * so we do unless unix extentions are active + * or "smbclient" is talking to us. + */ smb_maxcnt |= (upper_size<<16); if (upper_size > 1) { /* Can't do this on a chained packet. */ -- 1.8.1