[Samba] Test Failure for RW1 with samba-3.0.30, Solaris 9

I'm trying to build and install Samba 3.0.30 on a Solaris 9 SPARC machine.

When I do a "make test", the RW1 test is failing. If I go back and
configure and build 3.0.28 with the same settings, and do a make test,
everything passes. Here's what I'm seeing with 3.0.30:

---8<---
Testing RW1 (0)
TEST OUTPUT:
host=127.0.0.2 share=tmp user=root myname=cannes
Running RW1
starting readwritetest
unlink failed (NT_STATUS_OBJECT_NAME_NOT_FOUND) (normal, this file
should not exist)
Passed readwritetest v1: Yes
unlink failed (NT_STATUS_OBJECT_NAME_NOT_FOUND) (normal, this file
should not exist)
read failed (Read error: Error 0)
read -1, expected 130534
close failed (Read error: Error 0)
close failed (Read error: Error 0)
unlink failed (Read error: Error 0)
Passed readwritetest v2: No
tdis failed (Read error: Error 0)
TEST RW1 FAILED!
RW1 took 18.458818 secs

TEST FAILED: /export/data/software/cradle/build/samba-3.0.30/source/bin/smbtorture
//127.0.0.2/tmp -Uroot%test RW1 (status 1)
--->8---

Any pointers where to look next? I can see in the test that it's
failing on a cli_read() in rw_torture2(), but I don't know why. I
looked at st/smbd_test.log, but there are no errors there.

Thanks.

-David

--
David Eisner http://cradle.brokenglass.com
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Thu, May 29, 2008 at 3:19 PM, David Eisner <deisner@gmail.com> wrote:
> I'm trying to build and install Samba 3.0.30 on a Solaris 9 SPARC machine.
>
> When I do a "make test", the RW1 test is failing. If I go back and
> configure and build 3.0.28 with the same settings, and do a make test,
> everything passes. Here's what I'm seeing with 3.0.30:


More information, hoping one of the developers might point me in the
right direction (or tell me to file a bug report):

RW1 is implemented with torture.c:run_readwritetest(), which calls
rw_torture2(). This in turn runs through a loop where it writes and
reads randomly sized chunks of data. When this buffer size is larger
than about 130K, the error occurs. Here is the call stack:

1 1 rw_torture2 1 torture/torture.c
2 1 cli_read 619 torture/torture.c
3 1 cli_receive_smb 102 libsmb/clireadwrite.c
4 1 client_receive_smb 94 libsmb/clientgen.c
5 1 receive_smb_raw 61 libsmb/clientgen.c

Here is an example of the problem, with some debugging statements I
added into the code:

##DRE: rw_torture2: cli_read, buf_size == 130388
##DRE: cli_read: size = 130388
##DRE: receive_smb_raw: Invalid packet length! len == (130107 bytes),
buflen == (130048).
##DRE: receive_smb_raw: returning False 1
##DRE: client_receive_smb: returning 0
##DRE: cli_receive_smb: returning ret 0: 0
##DRE: cli_read: Returning -1 1
read failed (Read error: Error 0)
read -1, expected 130388

Here's where the problem begins, in receive_smb_raw:

BOOL receive_smb_raw(int fd, char *buffer, size_t buflen, unsigned int timeout)
{
ssize_t len,ret;

smb_read_error = 0;

len = read_smb_length_return_keepalive(fd,buffer,timeout );
// ...
if (len > buflen) {
//...

My interpretation of this is that the length of the packet read form
the server is larger than the buffer length specified in cli->bufsize,
and that this is "bad." Where should I look next? Thanks.

-David


--
David Eisner http://cradle.brokenglass.com
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

Hmm, I wonder if this isn't a bug with the fix for CVE-2008-1105.

I'll add a bug (to the 717 [1] "NEW" bugs for Samba 3.0 ...), but
here's what seems to be going on at a low level:

When the client state is setup in run_readwritetest() by way of
torture_open_connection(), cli_state->bufsize gets set to
CLI_SAMBA_MAX_LARGE_READX_SIZE, which is defined to be 127*1024 ==
130048.

During the rw_torture2 iteration that breaks the test,
send_file_readX() in smbd/reply.c calculates the packet length to
send:

nread = read_file(fsp,data,startpos,smb_maxcnt);
// ...

outsize = set_message(outbuf,12,nread,False);
// ...

/* Returning the number of bytes we want to send back - including header. */
return outsize;
}

When RW1 fails, nread == 130048 (which is
CLI_SAMBA_MAX_LARGE_READX_SIZE), and outsize is set by set_message()
to be 39 + 2x12 + nread == 130111.

Later on, construct_reply reduces this by 4, and I think this becomes
the length of the reply packet:

static int construct_reply(char *inbuf,char *outbuf,int size,int bufsize)
{
// ...
if(outsize > 4)
smb_setlen(outbuf,outsize - 4);
return(outsize);
}

Now the length stored in the packet is 130111 - 4 == 130107

Back on the client side, receive_smb_raw() (in lib/util_sock.c) is unhappy:

BOOL receive_smb_raw(int fd, char *buffer, size_t buflen, unsigned
int timeout)
{
// ...
len = read_smb_length_return_keepalive(fd,buffer,timeout );
// ...
if (len > buflen) {
DEBUG(0,("Invalid packet length! (%lu bytes).\n",(unsigned long)len));
//...

And here's the output (I added a debugging statement to also print buflen:

##DRE: receive_smb_raw: Invalid packet length! len == (130107 bytes),
buflen == (130048).

That is, it's complaining because 130107, the length reported in the
reply packet header (I think), is larger than bufsize for the client
state. As to where the real problem is (i.e. does receive_smb_raw()
need to do something with len before comparing it with buflen), I
can't say.

-David

[1] http://preview.tinyurl.com/6g6axu
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

It looks like a bug in smbtorture. I ran a 3.0.26a version of
smbtorture against a 3.0.30 server and it passes.

David Eisner wrote:
> Hmm, I wonder if this isn't a bug with the fix for CVE-2008-1105.
>
> I'll add a bug (to the 717 [1] "NEW" bugs for Samba 3.0 ...), but
> here's what seems to be going on at a low level:
>
> When the client state is setup in run_readwritetest() by way of
> torture_open_connection(), cli_state->bufsize gets set to
> CLI_SAMBA_MAX_LARGE_READX_SIZE, which is defined to be 127*1024 ==
> 130048.
>
> During the rw_torture2 iteration that breaks the test,
> send_file_readX() in smbd/reply.c calculates the packet length to
> send:
>
> nread = read_file(fsp,data,startpos,smb_maxcnt);
> // ...
>
> outsize = set_message(outbuf,12,nread,False);
> // ...
>
> /* Returning the number of bytes we want to send back - including header. */
> return outsize;
> }
>
> When RW1 fails, nread == 130048 (which is
> CLI_SAMBA_MAX_LARGE_READX_SIZE), and outsize is set by set_message()
> to be 39 + 2x12 + nread == 130111.
>
> Later on, construct_reply reduces this by 4, and I think this becomes
> the length of the reply packet:
>
> static int construct_reply(char *inbuf,char *outbuf,int size,int bufsize)
> {
> // ...
> if(outsize > 4)
> smb_setlen(outbuf,outsize - 4);
> return(outsize);
> }
>
> Now the length stored in the packet is 130111 - 4 == 130107
>
> Back on the client side, receive_smb_raw() (in lib/util_sock.c) is unhappy:
>
> BOOL receive_smb_raw(int fd, char *buffer, size_t buflen, unsigned
> int timeout)
> {
> // ...
> len = read_smb_length_return_keepalive(fd,buffer,timeout );
> // ...
> if (len > buflen) {
> DEBUG(0,("Invalid packet length! (%lu bytes).\n",(unsigned long)len));
> //...
>
> And here's the output (I added a debugging statement to also print buflen:
>
> ##DRE: receive_smb_raw: Invalid packet length! len == (130107 bytes),
> buflen == (130048).
>
> That is, it's complaining because 130107, the length reported in the
> reply packet header (I think), is larger than bufsize for the client
> state. As to where the real problem is (i.e. does receive_smb_raw()
> need to do something with len before comparing it with buflen), I
> can't say.
>
> -David
>
> [1] http://preview.tinyurl.com/6g6axu
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Mon, Jun 02, 2008 at 07:22:09PM -0400, David Eisner wrote:
> Hmm, I wonder if this isn't a bug with the fix for CVE-2008-1105.
>
> I'll add a bug (to the 717 [1] "NEW" bugs for Samba 3.0 ...), but
> here's what seems to be going on at a low level:
>
> When the client state is setup in run_readwritetest() by way of
> torture_open_connection(), cli_state->bufsize gets set to
> CLI_SAMBA_MAX_LARGE_READX_SIZE, which is defined to be 127*1024 ==
> 130048.
>
> During the rw_torture2 iteration that breaks the test,
> send_file_readX() in smbd/reply.c calculates the packet length to
> send:
>
> nread = read_file(fsp,data,startpos,smb_maxcnt);
> // ...
>
> outsize = set_message(outbuf,12,nread,False);
> // ...
>
> /* Returning the number of bytes we want to send back - including header. */
> return outsize;
> }
>
> When RW1 fails, nread == 130048 (which is
> CLI_SAMBA_MAX_LARGE_READX_SIZE), and outsize is set by set_message()
> to be 39 + 2x12 + nread == 130111.
>
> Later on, construct_reply reduces this by 4, and I think this becomes
> the length of the reply packet:
>
> static int construct_reply(char *inbuf,char *outbuf,int size,int bufsize)
> {
> // ...
> if(outsize > 4)
> smb_setlen(outbuf,outsize - 4);
> return(outsize);
> }
>
> Now the length stored in the packet is 130111 - 4 == 130107
>
> Back on the client side, receive_smb_raw() (in lib/util_sock.c) is unhappy:
>
> BOOL receive_smb_raw(int fd, char *buffer, size_t buflen, unsigned
> int timeout)
> {
> // ...
> len = read_smb_length_return_keepalive(fd,buffer,timeout );
> // ...
> if (len > buflen) {
> DEBUG(0,("Invalid packet length! (%lu bytes).\n",(unsigned long)len));
> //...
>
> And here's the output (I added a debugging statement to also print buflen:
>
> ##DRE: receive_smb_raw: Invalid packet length! len == (130107 bytes),
> buflen == (130048).
>
> That is, it's complaining because 130107, the length reported in the
> reply packet header (I think), is larger than bufsize for the client
> state. As to where the real problem is (i.e. does receive_smb_raw()
> need to do something with len before comparing it with buflen), I
> can't say.

Ah, I see the problem. CLI_SAMBA_MAX_LARGE_READX_SIZE is 127k
on the client, the server buffer size is 128k. For client large
readx/writex I should be allocating CLI_SAMBA_MAX_LARGE_READX_SIZE
+ LARGE_WRITEX_HDR_SIZE + SAFETY_MARGIN, not just
CLI_SAMBA_MAX_LARGE_READX_SIZE + SAFETY_MARGIN. It's safe as the
"safety margin" protects us but the client buffer detection
complains.

Try this patch against 3.0.x - should fix the problem.

Jeremy.

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Mon, Jun 2, 2008 at 9:29 PM, Jeremy Allison <jra@samba.org> wrote:
> Try this patch against 3.0.x - should fix the problem.
>
> Jeremy.


Yep, make test seems to be happy now. Thanks.

Should I still file a bug report?

-David


--
David Eisner http://cradle.brokenglass.com
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Tue, Jun 03, 2008 at 12:23:31PM -0400, David Eisner wrote:
> On Mon, Jun 2, 2008 at 9:29 PM, Jeremy Allison <jra@samba.org> wrote:
> > Try this patch against 3.0.x - should fix the problem.
> >
> > Jeremy.
>
>
> Yep, make test seems to be happy now. Thanks.
>
> Should I still file a bug report?

It might help so we can track it, thanks.

I've already committed this into all branches
so I'll close it out immediately, but at least
we'll have a bug id to hang user problems on.

Jeremy.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Tue, Jun 3, 2008 at 2:56 PM, Jeremy Allison <jra@samba.org> wrote:
>> Should I still file a bug report?
> It might help so we can track it, thanks.


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

Thanks again for your help.

-David


--
David Eisner http://cradle.brokenglass.com
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba