aboutsummaryrefslogtreecommitdiffstats
path: root/fs/cifs
diff options
context:
space:
mode:
authorJeff Layton <jlayton@redhat.com>2011-01-31 09:14:17 -0500
committerSteve French <sfrench@us.ibm.com>2011-01-31 17:35:37 -0500
commit6284644e8de1f4005166c918c3d2aa4c510ab9f6 (patch)
treec9498b41be7f8b569d02d203aeb169bafb63bbcb /fs/cifs
parentcab6958da0094e36a098751f844409fc9ee26251 (diff)
cifs: fix length checks in checkSMB
The cERROR message in checkSMB when the calculated length doesn't match the RFC1001 length is incorrect in many cases. It always says that the RFC1001 length is bigger than the SMB, even when it's actually the reverse. Fix the error message to say the reverse of what it does now when the SMB length goes beyond the end of the received data. Also, clarify the error message when the RFC length is too big. Finally, clarify the comments to show that the 512 byte limit on extra data at the end of the packet is arbitrary. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
Diffstat (limited to 'fs/cifs')
-rw-r--r--fs/cifs/misc.c33
1 files changed, 17 insertions, 16 deletions
diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
index 24f0a9d97ad8..2a930a752a78 100644
--- a/fs/cifs/misc.c
+++ b/fs/cifs/misc.c
@@ -478,25 +478,26 @@ checkSMB(struct smb_hdr *smb, __u16 mid, unsigned int length)
478 if (((4 + len) & 0xFFFF) == (clc_len & 0xFFFF)) 478 if (((4 + len) & 0xFFFF) == (clc_len & 0xFFFF))
479 return 0; /* bcc wrapped */ 479 return 0; /* bcc wrapped */
480 } 480 }
481 cFYI(1, "Calculated size %d vs length %d mismatch for mid %d", 481 cFYI(1, "Calculated size %u vs length %u mismatch for mid=%u",
482 clc_len, 4 + len, smb->Mid); 482 clc_len, 4 + len, smb->Mid);
483 /* Windows XP can return a few bytes too much, presumably 483
484 an illegal pad, at the end of byte range lock responses 484 if (4 + len < clc_len) {
485 so we allow for that three byte pad, as long as actual 485 cERROR(1, "RFC1001 size %u smaller than SMB for mid=%u",
486 received length is as long or longer than calculated length */
487 /* We have now had to extend this more, since there is a
488 case in which it needs to be bigger still to handle a
489 malformed response to transact2 findfirst from WinXP when
490 access denied is returned and thus bcc and wct are zero
491 but server says length is 0x21 bytes too long as if the server
492 forget to reset the smb rfc1001 length when it reset the
493 wct and bcc to minimum size and drop the t2 parms and data */
494 if ((4+len > clc_len) && (len <= clc_len + 512))
495 return 0;
496 else {
497 cERROR(1, "RFC1001 size %d bigger than SMB for Mid=%d",
498 len, smb->Mid); 486 len, smb->Mid);
499 return 1; 487 return 1;
488 } else if (len > clc_len + 512) {
489 /*
490 * Some servers (Windows XP in particular) send more
491 * data than the lengths in the SMB packet would
492 * indicate on certain calls (byte range locks and
493 * trans2 find first calls in particular). While the
494 * client can handle such a frame by ignoring the
495 * trailing data, we choose limit the amount of extra
496 * data to 512 bytes.
497 */
498 cERROR(1, "RFC1001 size %u more than 512 bytes larger "
499 "than SMB for mid=%u", len, smb->Mid);
500 return 1;
500 } 501 }
501 } 502 }
502 return 0; 503 return 0;