Created attachment 9841 [details]
Log of Samba dying

I was testing the Thursby DAVE Mac OS X SMB Client (I reproduced it with DAVE 9.0.2) with Samba 4.1.3, and ran into a problem where I just couldn't mount a particular share, as smbd would crash every time we tried to connect.

After taking a look at some Samba logs and packet captures of the issue, attached, it looks like the problem is because I was setting "max xmit = 65536". In the "Negotiate Protocol Resonse (0x72)" message that the server sends, it was sending this max buffer size to the client; 0x0100. DAVE was then sending a "Session Setup AndX Request (0x73)" that included a Max Buffer of 0, as this message only has a 16 bit field for the max buffer size (why it's a 32 bit field in the "negotiate protocol" response but a 16 bit field in the "Session Setup AndX" is beyond me). It looks like Samba accepted that value of 0, then died in this snippet of trans2.c after receiving a later trans2 request, as it calculated a useable_space of -60 for a max_send size of 0.

    /* When sending params and data ensure that both are nicely aligned */
    /* Only do this alignment when there is also data to send - else
        can cause NT redirector problems. */

    if (((params_to_send % 4) != 0) && (data_to_send != 0))
        data_alignment_offset = 4 - (params_to_send % 4);

    /* Space is bufsize minus Netbios over TCP header minus SMB header */
    /* The alignment_offset is to align the param bytes on an even byte
        boundary. NT 4.0 Beta needs this to work correctly. */

    useable_space = max_send - (smb_size
                    + 2 * 10 /* wct */
                    + alignment_offset
                    + data_alignment_offset);

    if (useable_space < 0) {
        DEBUG(0, ("send_trans2_replies failed sanity useable_space "
              "= %d!!!", useable_space));
        exit_server_cleanly("send_trans2_replies: Not enough space");
    }

Now, this is clearly a but in Thursby's DAVE, it shouldn't send a Max Buffer of 0, so I've reported it there. And it's also my bug, that I'm setting "max xmit" to a value greater than what the protocol supports. And furthermore, it seems like a pretty bad protocol bug, that the max buffer size is 32 bits in one message and 16 bits in another, but I have no idea where to file this bug in the protocol.

But it's also pretty bad that smbd just gives up and quits on this, rather that trying to do some kind of renegotiation or using some sane default value; I'm wondering if this can be fixed in Samba as well, by picking a sane default if it gets 0, capping max xmit to 65535, or something of the sort.