strange windows bug in byte range lock response invalid length

[Steven French]

I see a badly formed smb returned to the Linux cifs client by Windows XP
(service pack 1) server on a byte range lock response


byte range lock request ->
<- oplock break
oplock response ->
<- byte range lock response - success  (malformed)

the malformed byte range lock response has
RFC1001 length 0x2A
(byte range lock responses are supposed to be 0x27 bytes long as the wct
and bcc of this smb would imply
      0x20 bytes header + 1 (sizeof wct, wct = 2) + 4  (wct bytes) + 2
(sizeof bcc field) + 0 (bcc)

The smb is followed by a 3 byte pad of all zero (presumably) but not sure
why as 0x27 (calculated length) != 0x2A (actual rfc1001 length)

Anyone seen this?


I am fixing the Linux cifs client code to handle this (to relax the valid
smb size check a bit when
      actual rfc length > calculated length
by a small number of bytes

I think cifs version 1.36 or cifs 1.37 added a stricter check for the
calculated length so this problem probably does not show up in mainline
kernel or the distros fortunately but since byte range lock requests can
block forever this would have hung a process (since the client throws away
malformed smbs)



Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com