s3: smbd: In reply_read_and_X() SMB1 server is overwriting part of the 'reserved...

s3: smbd: In reply_read_and_X() SMB1 server is overwriting part of the 'reserved' zero fields with reply data length.

This occurred due to old code that used to do:

SSVAL(smb_buf(req->outbuf),-2,nread);

to set the reply length. This code was not needed,
as srv_set_message() was already correctly setting
the bcc length and was probably left from much
earlier legacy code.

However, in commit ddaa65ef6e049a185281c4d5deca4045e3b085e2
this was converted to do:

SSVAL(req->outbuf,smb_vwv11,smb_maxcnt);

This code actually overwrites the last 'reserved'
field in the SMB_COM_READ_ANDX packet reply, but we
never noticed as no client (or server code) looks at or
checks vwv11 in a SMB_COM_READ_ANDX reply.

[MS-SMB] shows for SMB_COM_READ_ANDX reply:

SMB_Parameters
{
        UCHAR WordCount;
        Words
        {
                UCHAR AndXCommand;
                UCHAR AndXReserved;
                USHORT AndXOffset;
                USHORT Available;
                USHORT DataCompactionMode;
                USHORT Reserved1;
                USHORT DataLength;
                USHORT DataOffset;
                USHORT DataLengthHigh;
                USHORT Reserved2[4];
        }
}
SMB_Data
{
        USHORT ByteCount;
        Bytes
        {
                UCHAR Pad[] (optional);
                UCHAR Data[variable];
        }

and indeed checking wireshark from Win2012R2
we find that smbd is writing the returned
read length into smb_vwv11 and Windows leaves
it as zeros (reserved).

Also fix the same problem in the named pipes code.

Torture test to ensure Reserved2[4] replies
are zero to follow.

https://bugzilla.samba.org/show_bug.cgi?id=11845

Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Alexander Bokovoy <ab@samba.org>