Created attachment 8219 [details] pcap file showing malformed ReadAndX reply Fadeeva Marina reported the following bug to the linux kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50841 After reproducing it and looking at traces, I'm fairly certain that this is a regression in recent versions of Samba. Specifically, I was able to reproduce it against this version in Fedora: samba-3.6.8-95.fc17.1.x86_64. The kernel negotiates a large rsize with the server. We then issue a read request with an odd size and the server sends back a malformed reply. Attaching a capture that shows the problem -- the malformed frame is #20. The TCP headers all look fine, but the SMB response just consists of 4 bytes of zeroes. Apparently this is a regression, but I'm not sure when it was introduced.
Bisecting the bs= value, if I issue the dd command with bs=131012, then it works fine. Larger sizes seem to hit similar problems, but if I issue one much larger (bs=135108 or so) then it works fine. Odd...
Created attachment 8220 [details] log while running smbd with -d10
Excerpt from the log at around the time the read request came in: is_locked: optimisation - exclusive oplock on file dd_file strict_lock_default: flavour = POSIX_LOCK brl start=0 len=131013 unlocked for fnum 10909 file dd_file streams_xattr_pread: offset=0, size=131013 read_file (dd_file): pos = 0, size = 131013, returned 131013 send_file_readX fnum=10909 max=131013 nread=131013 read_fd_with_timeout: blocking read. EOF from client. receive_smb_raw_talloc failed for client 192.168.1.22 read error = NT_STATUS_END_OF_FILE. setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 Security token: (NULL) UNIX token of user 0 Primary group is 0 and contains 0 supplementary groups change_to_root_user: now uid=(0,0) gid=(0,0) ...the NT_STATUS_END_OF_FILE error looks suspect...
Created attachment 8221 [details] Patch Can you try the attached patch?
Thanks Volker! Yes, that patch does seem to fix it...
Comment on attachment 8221 [details] Patch I don't know the code well enough to properly review it, but I did test it and it fixed the reported bug.
This is a blocker bug for 3.6.x. I think we also need a variant of this fix in master and 4.0.0. Jeremy.
(In reply to comment #7) > This is a blocker bug for 3.6.x. I think we also need a variant of this fix in > master and 4.0.0. from bad release date experiences we agreed that there are no blocker bugs in release branches any more. If the patch is there in time it will come in, if not it will come with the next release :-)
Well this one is a data corruption regression, so it's kind of bad. Plus we have a patch. That's why I called it a blocker :-).
Created attachment 8233 [details] git-am format patch for master and 4.0.0rc.next. Forward port to master and 4.0.0rc.next.
Re-assigning to Karolin to get : https://bugzilla.samba.org/attachment.cgi?id=8221 added to 3.6.next. Once Jeff or Volker have +1'ed the patch for master/4.0.0rc.next we can put it there too. Jeremy.
Comment on attachment 8233 [details] git-am format patch for master and 4.0.0rc.next. Ok, I think I sort of understand the patch happening. The code was artificially masking off the bits above 0x1FFFF in places where it should not have. This seems like it'll do the right thing then. That said, this code is really hard to follow with so many layers of macros that add pointless indirection. smb_len, smb_setlen, and their corresponding _large variants seem like pointless indirection into other macros...
Pushed to v3-6-test and autobuild-v4-0-test.
(In reply to comment #13) > Pushed to v3-6-test and autobuild-v4-0-test. Pushed to v4-0-test. Seems like it has not been pushed to master yet. Jeremy, would you like to push it to master? The bug report can be closed afterwards. Thanks!
(In reply to comment #14) > (In reply to comment #13) > > Pushed to v3-6-test and autobuild-v4-0-test. > > Pushed to v4-0-test. > > Seems like it has not been pushed to master yet. > Jeremy, would you like to push it to master? > The bug report can be closed afterwards. > > Thanks! Seeing patch in master (d5693d99b). Closing out bug report. Thanks!
*** Bug 9356 has been marked as a duplicate of this bug. ***