On Wed, 22 Dec 2010 08:39:07 -0500 Jeff Layton <jlayton@xxxxxxxxxx> 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 <marcus@xxxxxxxxxxxx> > Tested-by: Burkhard Obergoeker <burkhard.obergoeker@xxxxxxxxxxxxxxxx> > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> > --- > 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 <jlayton@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
