On Thu, Aug 14, 2014 at 2:30 PM, Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx> wrote: > On Tue, 12 Aug 2014 09:19:42 -0500 > Steve French <smfrench@xxxxxxxxx> wrote: > >> Writes fail to Mac servers with SMB2.1 mounts (works with cifs though) due >> to them sending an incorrect RFC1001 length. Workaround this problem. >> MacOS server sends a write response with 3 bytes of pad beyond the end >> of the SMB itself. The RFC1001 length is 3 bytes more than >> the sum of the SMB2.1 header length + the write reponse. >> >> Since we have seen a few other examples where servers have >> padded responses strangely (oplock break and create), >> allow servers to send a padded SMB2/SMB3 response to allow >> for rounding (up to 15 bytes). >> >> Signed-off-by: Steve French <smfrench@xxxxxxxxx> >> --- >> fs/cifs/smb2misc.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/fs/cifs/smb2misc.c b/fs/cifs/smb2misc.c >> index f2e6ac2..da05beb 100644 >> --- a/fs/cifs/smb2misc.c >> +++ b/fs/cifs/smb2misc.c >> @@ -181,6 +181,12 @@ smb2_check_message(char *buf, unsigned int length) >> /* server can return one byte more */ >> if (clc_len == 4 + len + 1) >> return 0; > > Not directly related to this patch, but... > > What's the story behind the check above? Allowing the server to overrun > the rfc1001 length by one byte seems dangerous... The problem IIRC was that at least one of the SMB2 requests/responses was defined with an implied data area which is at least 1 byte even if not present (might be SMB2 read since struct size is odd, 17). We had only run into one other case (oplock break response) where length check was off, so I prefer to stay stricter and safer if we don't know of any interoperability issues. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
