There exist two bugs in the handling of SMB responses that result
in remote kernel overflows. Due to the nature of the bugs both seem
to be very hard to exploit (in the sense of remote code execution
or local privilege escalation) but are trivial remote kernel crashes.

1) Bug 1 - read overflow

linux/fs/smbfs/proc.c

smb_proc_readX
smb_proc_read

data_len (returned from SMB) is not checked against count
This means if the server sends more than count bytes as reply
the memcpy will overflow

rated:
Even with local help very hard to exploit because the memory after the
buffer is always in a different offset to the next tast_struct
otherwise it would be trivial to overwrite the task_limit field
of a task owned by yourself which could later give root permissions.
(In combination with a information leak vulnerability this could
otherwise be called "Potential local root with remote help")


2) Bug 2 - trans2 reconstruction overflow

linux/fs/smbfs/sock.c

smb_receive_trans2

data_len (and parm_len) is increased with every new packet,
even if the packet contains the same data (offset, length)
of an already received packet. This means the loop
termination condition:

        if (data_len >= data_tot && parm_len >= parm_tot)
                break;

can be used to end with f.e. a data_len far bigger than data_to and
parm_len equal to parm_to

        inbuf = server->packet;
        if (buf_len >= server->packet_size) {
                server->packet_size = buf_len;
                server->packet = rcv_buf;
                rcv_buf = inbuf;
        } else {                                                     
                                                                     
                              
                PARANOIA("copying data, old size=%d, new size=%u\n",
                         server->packet_size, buf_len);
                memcpy(inbuf, rcv_buf, parm_len + data_len);
        }                                                            
                                                                     
                              

It is obvious that in such a case the memcpy will copy too much,
because data_len is > data_tot.

The data copied is after our buffer and therefore remote or
local code exploitation exploits seem impossible, because we only
have one shot or the kernel says goodbye...