[2.6 patch] fs/smbfs/request.c: turn NULL dereference into BUG()
In a case documented as
We should never be called with any of these states
BUG() in a case that would later result in a NULL pointer dereference.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 26 Mar 2005
--- linux-2.6.12-rc1-mm3-full/fs/smbfs/request.c.old2005-03-26
13:19:19.0 +0100
+++ linux-2.6.12-rc1-mm3-full/fs/smbfs/request.c2005-03-26
13:41:30.0 +0100
@@ -786,8 +642,7 @@ int smb_request_recv(struct smb_sb_info
/* We should never be called with any of these states */
case SMB_RECV_END:
case SMB_RECV_REQUEST:
- server->rstate = SMB_RECV_END;
- break;
+ BUG();
}
if (result < 0) {
-
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/
Re: [2.6 patch] fs/smbfs/request.c: turn NULL dereference into BUG()
Hi Andrew, all,
> In a case documented as
>
> We should never be called with any of these states
>
> BUG() in a case that would later result in a NULL pointer dereference.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> --- linux-2.6.12-rc1-mm3-full/fs/smbfs/request.c.old 2005-03-26
> 13:19:19.0 +0100
> +++ linux-2.6.12-rc1-mm3-full/fs/smbfs/request.c 2005-03-26
> 13:41:30.0 +0100
> @@ -786,8 +642,7 @@ int smb_request_recv(struct smb_sb_info
> /* We should never be called with any of these states */
> case SMB_RECV_END:
> case SMB_RECV_REQUEST:
> - server->rstate = SMB_RECV_END;
> - break;
> + BUG();
> }
>
> if (result < 0) {
Can you please pick this one for next -mm?
Thanks,
--
Jean Delvare
-
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/
Re: [2.6 patch] fs/smbfs/request.c: turn NULL dereference into BUG()
Hi Adrian, > On Sat, Mar 26, 2005 at 01:53:01PM +0100, Adrian Bunk wrote: > >... > > The problem is actually only in the SMB_RECV_END and > > SMB_RECV_REQUEST cases and all code after the NULL pointer > > dereference is actually dead code. > >... > > OK, this was also wrong... I can confirm, I gave it a try and had to reboot ;) You are right that the problem is only in the SMB_RECV_END and SMB_RECV_REQUEST cases. I had missed that point in the patch I proposed. > Third try. > (...) > In a case documented as > We should never be called with any of these states > BUG() in a case that would later result in a NULL pointer dereference. > (...) > --- linux-2.6.12-rc1-mm3-full/fs/smbfs/request.c.old 2005-03-26 > 13:19:19.0 +0100 > +++ linux-2.6.12-rc1-mm3-full/fs/smbfs/request.c 2005-03-26 > 13:41:30.0 +0100 > @@ -786,8 +642,7 @@ int smb_request_recv(struct smb_sb_info > /* We should never be called with any of these states */ > case SMB_RECV_END: > case SMB_RECV_REQUEST: > - server->rstate = SMB_RECV_END; > - break; > + BUG(); > } Yes, after reading the whole thing again, it seems to be the correct thing to do, providing that "should never" is a reference to an internal state and not something from the outside. I don't know myself, but you seem to do. Maybe someone from the samba team could confirm? BTW, it looks to me like Urban Widmark, the author of this module and supposedly the maintainer of it as well, has vanished some times ago. Last seen 2004-06-21, and no working e-mail address (both failes for me). Shouldn't we mark smbfs as unmaintained in MAINTAINERS, or have someone else take over? Any volunteer? Thanks, -- Jean Delvare - 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/
[2.6 patch] fs/smbfs/request.c: turn NULL dereference into BUG()
On Sat, Mar 26, 2005 at 01:53:01PM +0100, Adrian Bunk wrote:
>...
> The problem is actually only in the SMB_RECV_END and SMB_RECV_REQUEST
> cases and all code after the NULL pointer dereference is actually dead
> code.
>...
OK, this was also wrong...
Third try.
cu
Adrian
<-- snip -->
In a case documented as
We should never be called with any of these states
BUG() in a case that would later result in a NULL pointer dereference.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm3-full/fs/smbfs/request.c.old2005-03-26
13:19:19.0 +0100
+++ linux-2.6.12-rc1-mm3-full/fs/smbfs/request.c2005-03-26
13:41:30.0 +0100
@@ -786,8 +642,7 @@ int smb_request_recv(struct smb_sb_info
/* We should never be called with any of these states */
case SMB_RECV_END:
case SMB_RECV_REQUEST:
- server->rstate = SMB_RECV_END;
- break;
+ BUG();
}
if (result < 0) {
-
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/
[2.6 patch] fs/smbfs/request.c: turn NULL dereference into BUG()
On Sat, Mar 26, 2005 at 10:02:53AM +0100, Jean Delvare wrote:
> Hi all,
Hi Jean,
> Patch is broken, see:
> http://bugzilla.kernel.org/show_bug.cgi?id=4403
>
> Andrew, please back out from -mm.
agreed, thanks for reporting this.
> The smb_request_recv function is a complex one. The NULL dereference
> spotted by Coverity exists, but the fix proposed here doesn't properly
> address the problem.
>
> The big switch with fallthroughs and breaks all around the place is
> really tricky and hard to understand, admittedly. Not sure it is the
> best approach, BTW, but that's beyond the point.
>...
> The same is true for the SMB_RECV_END and SMB_REQUEST, but according to
> the comment these shouldn't happen anyway. As a side note, I wonder why
> there isn't even a warning thrown in the logs here, as we certainly
> would love to know when something happens that wasn't supposed to.
>
> My own proposed replacement patch follows. What to do in the
> SMB_RECV_END and SMB_REQUEST (and default?) cases depends on what the
> comment really means. If it means that the case should never happen
> unless there's a bug elsewhere in the kernel, then what I did is
> probably correct. But if the state is received from the outside and we
> have no control on it, then maybe attempting to still process the
> request the best we can might make sense. I don't know, people who do,
> please speak out.
>...
My impression is that your patch is incorrect, too.
The real problem seems to be:
<-- snip -->
...
/* We should never be called with any of these states */
case SMB_RECV_END:
case SMB_RECV_REQUEST:
server->rstate = SMB_RECV_END;
break;
...
if (server->rstate != SMB_RECV_END)
return 0;
result = 0;
if (req->rq_trans2_command && req->rq_rcls == SUCCESS)
result = smb_recv_trans2(server, req);
[more code]
...
<-- snip -->
A second try:
The problem is actually only in the SMB_RECV_END and SMB_RECV_REQUEST
cases and all code after the NULL pointer dereference is actually dead
code.
It turned out it removes much code, but unless I've made another mistake
in understanding the code in question, all it actually does is replacing
a NULL pointer dereference with a BUG().
The code after the NULL/BUG is also changed by this, but I'd expect that
in this "impossible" case the problems are bigger and there's no proper
handling anyway.
> Thanks.
>...
cu
Adrian
<-- snip -->
In a case documented as
We should never be called with any of these states
, replace a NULL pointer dereference with a BUG() and remove all code
that would only have been called after the NULL pointer dereference.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
fs/smbfs/request.c | 171 -
1 files changed, 1 insertion(+), 170 deletions(-)
--- linux-2.6.12-rc1-mm3-full/fs/smbfs/request.c.old2005-03-26
13:19:19.0 +0100
+++ linux-2.6.12-rc1-mm3-full/fs/smbfs/request.c2005-03-26
13:41:30.0 +0100
@@ -564,152 +564,8 @@ out:
return result;
}
/*
- * Receive a transaction2 response
- * Return: 0 if the response has been fully read
- * 1 if there are further "fragments" to read
- *<0 if there is an error
- */
-static int smb_recv_trans2(struct smb_sb_info *server, struct smb_request *req)
-{
- unsigned char *inbuf;
- unsigned int parm_disp, parm_offset, parm_count, parm_tot;
- unsigned int data_disp, data_offset, data_count, data_tot;
- int hdrlen = SMB_HEADER_LEN + req->rq_resp_wct*2 - 2;
-
- VERBOSE("handling trans2\n");
-
- inbuf = req->rq_header;
- data_tot= WVAL(inbuf, smb_tdrcnt);
- parm_tot= WVAL(inbuf, smb_tprcnt);
- parm_disp = WVAL(inbuf, smb_prdisp);
- parm_offset = WVAL(inbuf, smb_proff);
- parm_count = WVAL(inbuf, smb_prcnt);
- data_disp = WVAL(inbuf, smb_drdisp);
- data_offset = WVAL(inbuf, smb_droff);
- data_count = WVAL(inbuf, smb_drcnt);
-
- /* Modify offset for the split header/buffer we use */
- if (data_count || data_offset) {
- if (unlikely(data_offset < hdrlen))
- goto out_bad_data;
- else
- data_offset -= hdrlen;
- }
- if (parm_count || parm_offset) {
- if (unlikely(parm_offset < hdrlen))
- goto out_bad_parm;
- else
- parm_offset -= hdrlen;
- }
-
- if (parm_count == parm_tot && data_count == data_tot) {
- /*
-* This packet has all the trans2 data.
-*
-* We setup the request so that this will be the common
-* case. It may be a server error to not return a
-* response that fits.
-*/
- VERBOSE("single trans2 response
