On Wed, 22 Dec 2010 08:39:07 -0500 Jeff Layton <[email protected]> wrote:
> If the server sends us a RFC1001 length that's larger than the SMB, > then there's no reason to get our panties in a bunch and spew printk's, > and there's certainly no reason just ignore the response completely like > we do today. Just ignore the extra stuff on the end. > > This fixes: > > https://bugzilla.samba.org/show_bug.cgi?id=7860 > > Reported-by: Marcus Schopen <[email protected]> > Tested-by: Burkhard Obergoeker <[email protected]> > Signed-off-by: Jeff Layton <[email protected]> > --- > fs/cifs/misc.c | 25 ++++++------------------- > 1 files changed, 6 insertions(+), 19 deletions(-) > > diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c > index 43f1028..b3df037 100644 > --- a/fs/cifs/misc.c > +++ b/fs/cifs/misc.c Self-NAK on this patch. It eliminates the check for a RFC header that's too short to hold the calculated SMB lengths. After looking over the captures, it appears that removing that check is what allowed this to work against the server, which is sending SMB's with length fields that go beyond the end of the response. We'll need to rethink this approach. Steve suggested that we might be able to "fix up" the BCC and trans2 data lengths, but we need to consider whether that's reasonable to do in the general case. -- Jeff Layton <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
