* [PATCH] cifs: fix bad buffer length check in coalesce_t2
@ 2012-01-01 15:34 Jeff Layton
[not found] ` <CAH2r5msQU=_2X799oGt1MeuejSQX2HLLW4-FgnXqg6DXHwTTZA@mail.gmail.com>
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Jeff Layton @ 2012-01-01 15:34 UTC (permalink / raw)
To: smfrench; +Cc: linux-cifs, linux-kernel, k.skarlatos, shirishpargaonkar
The current check looks to see if the RFC1002 length is larger than
CIFSMaxBufSize, and fails if it is. The buffer is actually larger than
that by MAX_CIFS_HDR_SIZE.
This bug has been around for a long time, but the fact that we used to
cap the clients MaxBufferSize at the same level as the server tended
to paper over it. Commit c974befa changed that however and caused this
bug to bite in more cases.
Reported-and-Tested-by: Konstantinos Skarlatos <k.skarlatos@gmail.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
---
fs/cifs/connect.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 8cd4b52..27c4f25 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -282,7 +282,7 @@ static int coalesce_t2(struct smb_hdr *psecond, struct smb_hdr *pTargetSMB)
byte_count = be32_to_cpu(pTargetSMB->smb_buf_length);
byte_count += total_in_buf2;
/* don't allow buffer to overflow */
- if (byte_count > CIFSMaxBufSize)
+ if (byte_count > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE - 4)
return -ENOBUFS;
pTargetSMB->smb_buf_length = cpu_to_be32(byte_count);
--
1.7.7.4
^ permalink raw reply [flat|nested] 8+ messages in thread[parent not found: <CAH2r5msQU=_2X799oGt1MeuejSQX2HLLW4-FgnXqg6DXHwTTZA@mail.gmail.com>]
* Re: [PATCH] cifs: fix bad buffer length check in coalesce_t2
[not found] ` <CAH2r5msQU=_2X799oGt1MeuejSQX2HLLW4-FgnXqg6DXHwTTZA@mail.gmail.com>
@ 2012-01-02 11:09 ` Jeff Layton
0 siblings, 0 replies; 8+ messages in thread
From: Jeff Layton @ 2012-01-02 11:09 UTC (permalink / raw)
To: Steve French; +Cc: linux-cifs, k.skarlatos, shirishpargaonkar, linux-kernel
On Sun, 1 Jan 2012 17:35:18 -0600
Steve French <smfrench@gmail.com> wrote:
> Any easy repro?
Not for me. It seems to depend on a variety of factors including the
infolevel used, the length of the filenames, and possibly their order
in the response.
> On Jan 1, 2012 9:34 AM, "Jeff Layton" <jlayton@redhat.com> wrote:
>
> > The current check looks to see if the RFC1002 length is larger than
> > CIFSMaxBufSize, and fails if it is. The buffer is actually larger than
> > that by MAX_CIFS_HDR_SIZE.
> >
> > This bug has been around for a long time, but the fact that we used to
> > cap the clients MaxBufferSize at the same level as the server tended
> > to paper over it. Commit c974befa changed that however and caused this
> > bug to bite in more cases.
> >
> > Reported-and-Tested-by: Konstantinos Skarlatos <k.skarlatos@gmail.com>
> > Signed-off-by: Jeff Layton <jlayton@redhat.com>
> > ---
> > fs/cifs/connect.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> > index 8cd4b52..27c4f25 100644
> > --- a/fs/cifs/connect.c
> > +++ b/fs/cifs/connect.c
> > @@ -282,7 +282,7 @@ static int coalesce_t2(struct smb_hdr *psecond, struct
> > smb_hdr *pTargetSMB)
> > byte_count = be32_to_cpu(pTargetSMB->smb_buf_length);
> > byte_count += total_in_buf2;
> > /* don't allow buffer to overflow */
> > - if (byte_count > CIFSMaxBufSize)
> > + if (byte_count > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE - 4)
> > return -ENOBUFS;
> > pTargetSMB->smb_buf_length = cpu_to_be32(byte_count);
> >
> > --
> > 1.7.7.4
> >
> >
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] cifs: fix bad buffer length check in coalesce_t2
2012-01-01 15:34 [PATCH] cifs: fix bad buffer length check in coalesce_t2 Jeff Layton
[not found] ` <CAH2r5msQU=_2X799oGt1MeuejSQX2HLLW4-FgnXqg6DXHwTTZA@mail.gmail.com>
@ 2012-01-03 16:22 ` Shirish Pargaonkar
2012-01-03 22:46 ` Shirish Pargaonkar
2 siblings, 0 replies; 8+ messages in thread
From: Shirish Pargaonkar @ 2012-01-03 16:22 UTC (permalink / raw)
To: Jeff Layton; +Cc: smfrench, linux-cifs, linux-kernel, k.skarlatos
On Sun, Jan 1, 2012 at 9:34 AM, Jeff Layton <jlayton@redhat.com> wrote:
> The current check looks to see if the RFC1002 length is larger than
> CIFSMaxBufSize, and fails if it is. The buffer is actually larger than
> that by MAX_CIFS_HDR_SIZE.
>
> This bug has been around for a long time, but the fact that we used to
> cap the clients MaxBufferSize at the same level as the server tended
> to paper over it. Commit c974befa changed that however and caused this
> bug to bite in more cases.
>
> Reported-and-Tested-by: Konstantinos Skarlatos <k.skarlatos@gmail.com>
> Signed-off-by: Jeff Layton <jlayton@redhat.com>
> ---
> fs/cifs/connect.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index 8cd4b52..27c4f25 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -282,7 +282,7 @@ static int coalesce_t2(struct smb_hdr *psecond, struct smb_hdr *pTargetSMB)
> byte_count = be32_to_cpu(pTargetSMB->smb_buf_length);
> byte_count += total_in_buf2;
> /* don't allow buffer to overflow */
> - if (byte_count > CIFSMaxBufSize)
> + if (byte_count > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE - 4)
> return -ENOBUFS;
> pTargetSMB->smb_buf_length = cpu_to_be32(byte_count);
>
> --
> 1.7.7.4
>
Tested-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Tested cifs module built with this patch against a Windows XP server
where the failure was noticed.
But even without this patch, there are no errors against Windows 2003 server
and Windows 2008 server.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH] cifs: fix bad buffer length check in coalesce_t2
2012-01-01 15:34 [PATCH] cifs: fix bad buffer length check in coalesce_t2 Jeff Layton
[not found] ` <CAH2r5msQU=_2X799oGt1MeuejSQX2HLLW4-FgnXqg6DXHwTTZA@mail.gmail.com>
2012-01-03 16:22 ` Shirish Pargaonkar
@ 2012-01-03 22:46 ` Shirish Pargaonkar
2012-01-04 14:09 ` Jeff Layton
2 siblings, 1 reply; 8+ messages in thread
From: Shirish Pargaonkar @ 2012-01-03 22:46 UTC (permalink / raw)
To: Jeff Layton; +Cc: smfrench, linux-kernel, k.skarlatos
On Sun, Jan 1, 2012 at 9:34 AM, Jeff Layton <jlayton@redhat.com> wrote:
> The current check looks to see if the RFC1002 length is larger than
> CIFSMaxBufSize, and fails if it is. The buffer is actually larger than
> that by MAX_CIFS_HDR_SIZE.
>
> This bug has been around for a long time, but the fact that we used to
> cap the clients MaxBufferSize at the same level as the server tended
> to paper over it. Commit c974befa changed that however and caused this
> bug to bite in more cases.
>
> Reported-and-Tested-by: Konstantinos Skarlatos <k.skarlatos@gmail.com>
> Signed-off-by: Jeff Layton <jlayton@redhat.com>
> ---
> fs/cifs/connect.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index 8cd4b52..27c4f25 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -282,7 +282,7 @@ static int coalesce_t2(struct smb_hdr *psecond, struct smb_hdr *pTargetSMB)
> byte_count = be32_to_cpu(pTargetSMB->smb_buf_length);
> byte_count += total_in_buf2;
> /* don't allow buffer to overflow */
> - if (byte_count > CIFSMaxBufSize)
> + if (byte_count > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE - 4)
> return -ENOBUFS;
> pTargetSMB->smb_buf_length = cpu_to_be32(byte_count);
>
> --
> 1.7.7.4
>
This looks correct. But the way Windows XP server responds to request
trans2/find_first2/info level is different than how Windows 2003 Server
and Windows 2008 Server respond.
So a related concern would be, for a response from Windows XP server,
this check in function check2ndT2 does not make sense.
if (total_data_size > CIFSMaxBufSize) {
It is possible to have large number of entries in a directory such that the
response to a ls command can exceed CIFSMaxBufSize.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH] cifs: fix bad buffer length check in coalesce_t2
2012-01-03 22:46 ` Shirish Pargaonkar
@ 2012-01-04 14:09 ` Jeff Layton
2012-01-04 15:08 ` Shirish Pargaonkar
2012-01-04 16:14 ` Steve French
0 siblings, 2 replies; 8+ messages in thread
From: Jeff Layton @ 2012-01-04 14:09 UTC (permalink / raw)
To: Shirish Pargaonkar; +Cc: smfrench, linux-kernel, k.skarlatos
On Tue, 3 Jan 2012 16:46:15 -0600
Shirish Pargaonkar <shirishpargaonkar@gmail.com> wrote:
> On Sun, Jan 1, 2012 at 9:34 AM, Jeff Layton <jlayton@redhat.com> wrote:
> > The current check looks to see if the RFC1002 length is larger than
> > CIFSMaxBufSize, and fails if it is. The buffer is actually larger than
> > that by MAX_CIFS_HDR_SIZE.
> >
> > This bug has been around for a long time, but the fact that we used to
> > cap the clients MaxBufferSize at the same level as the server tended
> > to paper over it. Commit c974befa changed that however and caused this
> > bug to bite in more cases.
> >
> > Reported-and-Tested-by: Konstantinos Skarlatos <k.skarlatos@gmail.com>
> > Signed-off-by: Jeff Layton <jlayton@redhat.com>
> > ---
> > fs/cifs/connect.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> > index 8cd4b52..27c4f25 100644
> > --- a/fs/cifs/connect.c
> > +++ b/fs/cifs/connect.c
> > @@ -282,7 +282,7 @@ static int coalesce_t2(struct smb_hdr *psecond, struct smb_hdr *pTargetSMB)
> > byte_count = be32_to_cpu(pTargetSMB->smb_buf_length);
> > byte_count += total_in_buf2;
> > /* don't allow buffer to overflow */
> > - if (byte_count > CIFSMaxBufSize)
> > + if (byte_count > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE - 4)
> > return -ENOBUFS;
> > pTargetSMB->smb_buf_length = cpu_to_be32(byte_count);
> >
> > --
> > 1.7.7.4
> >
>
> This looks correct. But the way Windows XP server responds to request
> trans2/find_first2/info level is different than how Windows 2003 Server
> and Windows 2008 Server respond.
>
> So a related concern would be, for a response from Windows XP server,
> this check in function check2ndT2 does not make sense.
> if (total_data_size > CIFSMaxBufSize) {
>
This check looks redundant to me. We could remove it since the check in
coalesce_t2 is more accurate...
> It is possible to have large number of entries in a directory such that the
> response to a ls command can exceed CIFSMaxBufSize.
It shouldn't be possible. The CIFSFindFirst request sends this:
pSMB->MaxDataCount = cpu_to_le16(CIFSMaxBufSize & 0xFFFFFF00);
...which should ensure that the amount of data in the response is less
than CIFSMaxBufSize. I'm not sure what the point of the mask is there
however...
In addition, we're also limited by this:
pSMB->SearchCount = cpu_to_le16(CIFSMaxBufSize/sizeof(FILE_UNIX_INFO));
...but I think we ought to consider just setting that to 0xffff.
Dividing by sizeof(FILE_UNIX_INFO) is clearly wrong for other
infolevels. We don't really care how many entries the server sends as
long as it doesn't exceed the buffer size.
Either way, I believe this patch is correct, though we may have some
other cleanup work to do in this area.
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH] cifs: fix bad buffer length check in coalesce_t2
2012-01-04 14:09 ` Jeff Layton
@ 2012-01-04 15:08 ` Shirish Pargaonkar
2012-01-04 16:14 ` Steve French
1 sibling, 0 replies; 8+ messages in thread
From: Shirish Pargaonkar @ 2012-01-04 15:08 UTC (permalink / raw)
To: Jeff Layton; +Cc: smfrench, linux-kernel, k.skarlatos
On Wed, Jan 4, 2012 at 8:09 AM, Jeff Layton <jlayton@redhat.com> wrote:
> On Tue, 3 Jan 2012 16:46:15 -0600
> Shirish Pargaonkar <shirishpargaonkar@gmail.com> wrote:
>
>> On Sun, Jan 1, 2012 at 9:34 AM, Jeff Layton <jlayton@redhat.com> wrote:
>> > The current check looks to see if the RFC1002 length is larger than
>> > CIFSMaxBufSize, and fails if it is. The buffer is actually larger than
>> > that by MAX_CIFS_HDR_SIZE.
>> >
>> > This bug has been around for a long time, but the fact that we used to
>> > cap the clients MaxBufferSize at the same level as the server tended
>> > to paper over it. Commit c974befa changed that however and caused this
>> > bug to bite in more cases.
>> >
>> > Reported-and-Tested-by: Konstantinos Skarlatos <k.skarlatos@gmail.com>
>> > Signed-off-by: Jeff Layton <jlayton@redhat.com>
>> > ---
>> > fs/cifs/connect.c | 2 +-
>> > 1 files changed, 1 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
>> > index 8cd4b52..27c4f25 100644
>> > --- a/fs/cifs/connect.c
>> > +++ b/fs/cifs/connect.c
>> > @@ -282,7 +282,7 @@ static int coalesce_t2(struct smb_hdr *psecond, struct smb_hdr *pTargetSMB)
>> > byte_count = be32_to_cpu(pTargetSMB->smb_buf_length);
>> > byte_count += total_in_buf2;
>> > /* don't allow buffer to overflow */
>> > - if (byte_count > CIFSMaxBufSize)
>> > + if (byte_count > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE - 4)
>> > return -ENOBUFS;
>> > pTargetSMB->smb_buf_length = cpu_to_be32(byte_count);
>> >
>> > --
>> > 1.7.7.4
>> >
>>
>> This looks correct. But the way Windows XP server responds to request
>> trans2/find_first2/info level is different than how Windows 2003 Server
>> and Windows 2008 Server respond.
>>
>> So a related concern would be, for a response from Windows XP server,
>> this check in function check2ndT2 does not make sense.
>> if (total_data_size > CIFSMaxBufSize) {
>>
>
> This check looks redundant to me. We could remove it since the check in
> coalesce_t2 is more accurate...
>
>> It is possible to have large number of entries in a directory such that the
>> response to a ls command can exceed CIFSMaxBufSize.
>
> It shouldn't be possible. The CIFSFindFirst request sends this:
>
> pSMB->MaxDataCount = cpu_to_le16(CIFSMaxBufSize & 0xFFFFFF00);
>
> ...which should ensure that the amount of data in the response is less
> than CIFSMaxBufSize. I'm not sure what the point of the mask is there
> however...
>
> In addition, we're also limited by this:
>
> pSMB->SearchCount = cpu_to_le16(CIFSMaxBufSize/sizeof(FILE_UNIX_INFO));
>
> ...but I think we ought to consider just setting that to 0xffff.
>
> Dividing by sizeof(FILE_UNIX_INFO) is clearly wrong for other
> infolevels. We don't really care how many entries the server sends as
> long as it doesn't exceed the buffer size.
>
> Either way, I believe this patch is correct, though we may have some
yes, agree.
> other cleanup work to do in this area.
>
> --
> Jeff Layton <jlayton@redhat.com>
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH] cifs: fix bad buffer length check in coalesce_t2
2012-01-04 14:09 ` Jeff Layton
2012-01-04 15:08 ` Shirish Pargaonkar
@ 2012-01-04 16:14 ` Steve French
2012-01-04 16:29 ` Jeff Layton
1 sibling, 1 reply; 8+ messages in thread
From: Steve French @ 2012-01-04 16:14 UTC (permalink / raw)
To: Jeff Layton; +Cc: Shirish Pargaonkar, linux-kernel, k.skarlatos, linux-cifs
FYI - the patch is merged into cifs git tree but want to wait 24 hours
for linux-next before sending merge request upstream.
On Wed, Jan 4, 2012 at 8:09 AM, Jeff Layton <jlayton@redhat.com> wrote:
> On Tue, 3 Jan 2012 16:46:15 -0600
> Shirish Pargaonkar <shirishpargaonkar@gmail.com> wrote:
>
>> On Sun, Jan 1, 2012 at 9:34 AM, Jeff Layton <jlayton@redhat.com> wrote:
>> > The current check looks to see if the RFC1002 length is larger than
>> > CIFSMaxBufSize, and fails if it is. The buffer is actually larger than
>> > that by MAX_CIFS_HDR_SIZE.
>> >
>> > This bug has been around for a long time, but the fact that we used to
>> > cap the clients MaxBufferSize at the same level as the server tended
>> > to paper over it. Commit c974befa changed that however and caused this
>> > bug to bite in more cases.
>> >
>> > Reported-and-Tested-by: Konstantinos Skarlatos <k.skarlatos@gmail.com>
>> > Signed-off-by: Jeff Layton <jlayton@redhat.com>
>> > ---
>> > fs/cifs/connect.c | 2 +-
>> > 1 files changed, 1 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
>> > index 8cd4b52..27c4f25 100644
>> > --- a/fs/cifs/connect.c
>> > +++ b/fs/cifs/connect.c
>> > @@ -282,7 +282,7 @@ static int coalesce_t2(struct smb_hdr *psecond, struct smb_hdr *pTargetSMB)
>> > byte_count = be32_to_cpu(pTargetSMB->smb_buf_length);
>> > byte_count += total_in_buf2;
>> > /* don't allow buffer to overflow */
>> > - if (byte_count > CIFSMaxBufSize)
>> > + if (byte_count > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE - 4)
>> > return -ENOBUFS;
>> > pTargetSMB->smb_buf_length = cpu_to_be32(byte_count);
>> >
>> > --
>> > 1.7.7.4
>> >
>>
>> This looks correct. But the way Windows XP server responds to request
>> trans2/find_first2/info level is different than how Windows 2003 Server
>> and Windows 2008 Server respond.
>>
>> So a related concern would be, for a response from Windows XP server,
>> this check in function check2ndT2 does not make sense.
>> if (total_data_size > CIFSMaxBufSize) {
>>
>
> This check looks redundant to me. We could remove it since the check in
> coalesce_t2 is more accurate...
>
>> It is possible to have large number of entries in a directory such that the
>> response to a ls command can exceed CIFSMaxBufSize.
>
> It shouldn't be possible. The CIFSFindFirst request sends this:
>
> pSMB->MaxDataCount = cpu_to_le16(CIFSMaxBufSize & 0xFFFFFF00);
>
> ...which should ensure that the amount of data in the response is less
> than CIFSMaxBufSize. I'm not sure what the point of the mask is there
> however...
>
> In addition, we're also limited by this:
>
> pSMB->SearchCount = cpu_to_le16(CIFSMaxBufSize/sizeof(FILE_UNIX_INFO));
>
> ...but I think we ought to consider just setting that to 0xffff.
>
> Dividing by sizeof(FILE_UNIX_INFO) is clearly wrong for other
> infolevels. We don't really care how many entries the server sends as
> long as it doesn't exceed the buffer size.
>
> Either way, I believe this patch is correct, though we may have some
> other cleanup work to do in this area.
>
> --
> Jeff Layton <jlayton@redhat.com>
--
Thanks,
Steve
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH] cifs: fix bad buffer length check in coalesce_t2
2012-01-04 16:14 ` Steve French
@ 2012-01-04 16:29 ` Jeff Layton
0 siblings, 0 replies; 8+ messages in thread
From: Jeff Layton @ 2012-01-04 16:29 UTC (permalink / raw)
To: Steve French; +Cc: Shirish Pargaonkar, linux-kernel, k.skarlatos, linux-cifs
On Wed, 4 Jan 2012 10:14:25 -0600
Steve French <smfrench@gmail.com> wrote:
> FYI - the patch is merged into cifs git tree but want to wait 24 hours
> for linux-next before sending merge request upstream.
>
I wouldn't wait. The 3.2 release is imminent.
> On Wed, Jan 4, 2012 at 8:09 AM, Jeff Layton <jlayton@redhat.com> wrote:
> > On Tue, 3 Jan 2012 16:46:15 -0600
> > Shirish Pargaonkar <shirishpargaonkar@gmail.com> wrote:
> >
> >> On Sun, Jan 1, 2012 at 9:34 AM, Jeff Layton <jlayton@redhat.com> wrote:
> >> > The current check looks to see if the RFC1002 length is larger than
> >> > CIFSMaxBufSize, and fails if it is. The buffer is actually larger than
> >> > that by MAX_CIFS_HDR_SIZE.
> >> >
> >> > This bug has been around for a long time, but the fact that we used to
> >> > cap the clients MaxBufferSize at the same level as the server tended
> >> > to paper over it. Commit c974befa changed that however and caused this
> >> > bug to bite in more cases.
> >> >
> >> > Reported-and-Tested-by: Konstantinos Skarlatos <k.skarlatos@gmail.com>
> >> > Signed-off-by: Jeff Layton <jlayton@redhat.com>
> >> > ---
> >> > fs/cifs/connect.c | 2 +-
> >> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >> >
> >> > diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> >> > index 8cd4b52..27c4f25 100644
> >> > --- a/fs/cifs/connect.c
> >> > +++ b/fs/cifs/connect.c
> >> > @@ -282,7 +282,7 @@ static int coalesce_t2(struct smb_hdr *psecond, struct smb_hdr *pTargetSMB)
> >> > byte_count = be32_to_cpu(pTargetSMB->smb_buf_length);
> >> > byte_count += total_in_buf2;
> >> > /* don't allow buffer to overflow */
> >> > - if (byte_count > CIFSMaxBufSize)
> >> > + if (byte_count > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE - 4)
> >> > return -ENOBUFS;
> >> > pTargetSMB->smb_buf_length = cpu_to_be32(byte_count);
> >> >
> >> > --
> >> > 1.7.7.4
> >> >
> >>
> >> This looks correct. But the way Windows XP server responds to request
> >> trans2/find_first2/info level is different than how Windows 2003 Server
> >> and Windows 2008 Server respond.
> >>
> >> So a related concern would be, for a response from Windows XP server,
> >> this check in function check2ndT2 does not make sense.
> >> if (total_data_size > CIFSMaxBufSize) {
> >>
> >
> > This check looks redundant to me. We could remove it since the check in
> > coalesce_t2 is more accurate...
> >
> >> It is possible to have large number of entries in a directory such that the
> >> response to a ls command can exceed CIFSMaxBufSize.
> >
> > It shouldn't be possible. The CIFSFindFirst request sends this:
> >
> > pSMB->MaxDataCount = cpu_to_le16(CIFSMaxBufSize & 0xFFFFFF00);
> >
> > ...which should ensure that the amount of data in the response is less
> > than CIFSMaxBufSize. I'm not sure what the point of the mask is there
> > however...
> >
> > In addition, we're also limited by this:
> >
> > pSMB->SearchCount = cpu_to_le16(CIFSMaxBufSize/sizeof(FILE_UNIX_INFO));
> >
> > ...but I think we ought to consider just setting that to 0xffff.
> >
> > Dividing by sizeof(FILE_UNIX_INFO) is clearly wrong for other
> > infolevels. We don't really care how many entries the server sends as
> > long as it doesn't exceed the buffer size.
> >
> > Either way, I believe this patch is correct, though we may have some
> > other cleanup work to do in this area.
> >
> > --
> > Jeff Layton <jlayton@redhat.com>
>
>
>
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-01-04 16:29 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-01 15:34 [PATCH] cifs: fix bad buffer length check in coalesce_t2 Jeff Layton
[not found] ` <CAH2r5msQU=_2X799oGt1MeuejSQX2HLLW4-FgnXqg6DXHwTTZA@mail.gmail.com>
2012-01-02 11:09 ` Jeff Layton
2012-01-03 16:22 ` Shirish Pargaonkar
2012-01-03 22:46 ` Shirish Pargaonkar
2012-01-04 14:09 ` Jeff Layton
2012-01-04 15:08 ` Shirish Pargaonkar
2012-01-04 16:14 ` Steve French
2012-01-04 16:29 ` Jeff Layton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®