Re: [PATCH][CIFS] Workaround MacOS server problem with SMB2.1 write response

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux