Bug 2918 - Samba server forever sends tree_connect_andx responses after unlink chained to treeconnect failed with NT_STATUS_SHARING_VIOLATION
Summary: Samba server forever sends tree_connect_andx responses after unlink chained t...
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.14a
Hardware: All Linux
: P3 normal
Target Milestone: none
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
Depends on:
Reported: 2005-07-25 10:40 UTC by Aaron Staley
Modified: 2005-08-24 10:25 UTC (History)
0 users

See Also:

Patch. (1.92 KB, patch)
2005-07-26 10:55 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Staley 2005-07-25 10:40:22 UTC
Consider the following sequence of CIFS commands:

-Open_AndX some file "A", allowing create.  Generally, this will pass.
-Open a new tree -> andx chained to a unlink of that file "A". (e.g.
TreeConnect_AndX chained to Unlink).  This should fail with
-Disconnect From that new tree (Tree_Disconnect).
-Returning to old true, Close file A.

After this sequence of commands (which samba responds as expected to), the samba
server will continually send responses to TreeConnect_AndX (although with no
unlink chained to it). with some invalid Mid.  It will not respond to any
subsequent requests from the client; rather, it will continue flooding the
client with Tree_Connect responses.

A close or unlink appears necessary to triggering this problem.
Comment 1 Jeremy Allison 2005-07-25 11:14:04 UTC
Can you send me a some client code or binary that will send this sequence please
so I can debug this ?
Comment 2 Gerald (Jerry) Carter (dead mail address) 2005-07-26 05:55:21 UTC
Aaron, please try to keep the comments in the bug report rather 
than replying to email.  It allows us to track things better
between developers.

--------- forwarded mail -------------------------
Well, it is actually in the form of a samba 4 torture test:

Add this to torture/torture.c:

*/Samba bug that occurs with chained treecon/unlink*/
BOOL torture_samba_inf_response(void) {
   char * fname = "samba_inf.txt";
   struct smbcli_state *cli;
     struct smbcli_request *req = NULL;
   if (!torture_open_connection(&cli)) {
       printf("Couldn't open connection!\n");
       return False;
     d_printf("Opening %s\n",fname);
   int fnum = smbcli_open(cli->tree, fname, O_RDWR | O_TRUNC | O_CREAT, DENY_NONE);
     d_printf("running tcon chained with unlink\n");
   int tid = cli->tree->tid;
   req = smbcli_request_setup(cli->tree, SMBtconX, 4, 0);
   SSVAL(req->out.vwv, VWV(0), SMB_CHAIN_NONE);
   SSVAL(req->out.vwv, VWV(1), 0);
   SSVAL(req->out.vwv, VWV(2), 0);
   DATA_BLOB pw = data_blob(NULL, 0);
   SSVAL(req->out.vwv, VWV(3), pw.length);
         smbcli_req_append_blob(req,  &pw);
   smbcli_req_append_string(req,lp_parm_string(-1, "torture", "share"),  
   smbcli_req_append_string(req,"?????", STR_TERMINATE | STR_ASCII);      
   smbcli_chained_request_setup(req, SMBunlink, 1, 0);
/*correct samba4 torture "bug" w/ chained setup*/
   req->out.data_size = 0;
   req->out.data = req->out.vwv + VWV(1)+2;
   req->out.wct = 1;
   smbcli_req_append_ascii4(req, fname, STR_TERMINATE);

     if (!smbcli_request_send(req)|| !smbcli_request_receive(req)) {
       return False;
     /*tree_connect receive.*/      cli->tree->tid = SVAL(req->in.hdr, HDR_TID);
   d_printf("disconnecting from new tree\n");      smb_tree_disconnect(cli->tree);
     cli->tree->tid = tid; /*return to old tree*/      d_printf("closing file\n");
     d_printf("removing file\n");
   NTSTATUS ret = smbcli_unlink(cli->tree,fname);
   return NT_STATUS_IS_OK(ret);

and the torture-op:
{"TreeConUnlink", torture_samba_inf_response, 0}, /*test for samba*/

and of course:
bin/smbtorture '\\server\share' TreeConUnlink

to launch the test.

This test passes on a windows 2000 server.  On a samba server, it will time-out
after 60 seconds (no response is received for the Delete SMB command).  With
samba set to debug level 1, the many unmatched reply messages can be seen.

Comment 3 Jeremy Allison 2005-07-26 10:55:58 UTC
Created attachment 1337 [details]

This should fix it.
Comment 4 Jeremy Allison 2005-07-26 10:56:44 UTC
The problem was using Inbuffer to push a deferred open message onto the queue
when we're in a chained message set - we're actually processing a different
buffer then. Added current_inbuf as a static inside smbd/process.c to ensure the
correct message gets pushed and processed.
Comment 5 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:25:52 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.