You are correct that the CIFS code calls SendReceive in cases in which the buffer may be too small to fit a large SMB response, and that should be fixed (e.g. to avoid possible overflows due to a server bug), None of the eight cases (SMB TreeDisconnect, SMB uLogoff, SMB Close, SMB FindClose etc.) in which a small buffer is passed in to SendReceive return more than a few dozen bytes (and they are fixed size responses), but I agree that we have to be safe (and we have seen at least one server corrupt the bcc in the ulogoffX response and another on the NTCreateX response) so it would be good to fix.
There are probably better ways to handle this though than passing in the buffer size as your patch does. Since there are only two buffer sizes that CIFS uses - it would be easier to pass in (or out) a flag which indicates the buffer size. But the function SendReceive2 already does that - and the easier way to handle this seems to be changing the eight places in fs/cifs/cifssmb.c which call small_smb_init and then call SendReceive, to call SendReceive2 instead. > From: Przemyslaw Wegrzyn <[EMAIL PROTECTED]> > To: linux-kernel@vger.kernel.org > Subject: Buffer overflow in CIFS VFS. > > just to find something that looks like a buffer overflow bug. > The problem is in SendReceive() function in transport.c - it memcpy's > message payload into a buffer passed via out_buf param. The function > assumes that all buffers are of size (CIFSMaxBufSize + > MAX_CIFS_HDR_SIZE) , unfortunately it is also called with smaller > (MAX_CIFS_SMALL_BUFFER_SIZE) buffers. > > To check this finding I patched Samba server to send oversized logoffX > messages. With ~ 16kB messages the client running 2.6.23.1 crashed upon > unmounting. > > I've done a quick fix, available here: > http://czajnick.sitenet.pl/cifs-buffer-overflow-fix.patch.gz -- Thanks, Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
