From: Jeff Layton <jlayton@samba.org>
To: Steve French <smfrench@gmail.com>
Cc: "linux-cifs@vger.kernel.org" <linux-cifs@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/4] [SMB3] Fix dereference before null check warning
Date: Wed, 1 Apr 2015 07:07:00 -0400 [thread overview]
Message-ID: <20150401070700.268628b2@tlielax.poochiereds.net> (raw)
In-Reply-To: <CAH2r5ms4p5FYcxW4E1FJ=1DCJstDgOdTDETPEWoW9bxWmJ2O_g@mail.gmail.com>
On Wed, 1 Apr 2015 00:00:57 -0500
Steve French <smfrench@gmail.com> wrote:
> On Tue, Mar 31, 2015 at 7:46 PM, Jeff Layton <jlayton@poochiereds.net> wrote:
> > On Fri, 27 Mar 2015 00:28:01 -0500
> > Steve French <smfrench@gmail.com> wrote:
> >
> >> null tcon is not likely in these paths in current
> >> code, but obviously it does clarify the code to
> >> check for null (if at all) before derefrencing
> >> rather than after.
> >>
> >> Reported by Coverity (CID 1042666)
> >>
> >> Signed-off-by: Steve French <smfrench@gmail.com>
> >
> > I don't get it. Under what circumstances would the tcon ever be NULL
> > here? If there aren't any then this is just confusing. It would be
> > better to just remove the bogus checks for a NULL tcon instead.
>
> I don't think it really matters much one way or another but I agree it
> would be a bug to pass in a null tcon to SMB2_ioctl.
>
> On the other hand ... if there are any paths where tcon might be null
> (other than SessionSetup and NegProt and TCon itself) due to bug,
> SMB2/SMB3 ioctl/fsctl would be the one since there are various strange
> operations (such as security related calls such as validate negotiate
> for example) that either call it now or will need to call it as
> additional SMB2/SMB3 ioctls are added. I didn't see any harm in
> checking for null tcon, although clearly passing in a null tcon would
> be a bug - this is one code path where I don't mind checking since
> there are some counterintuitive things which SMB2 ioctl/fsctl protocol
> operations do.
>
I guess my thinking was that an ioctl syscall requires that you have an
open file, and that requires a fully-established tcon with cifs.ko. So
I don't quite understand how you could get into SMB2_ioctl and not have
a valid tcon.
Bogus NULL pointer checks like this may seem harmless, but they tend to
lead toward the papering over of real bugs. My suggestion would be to
get rid of any pretense that passing in a NULL tcon is OK here.
>
> >> ---
> >> fs/cifs/smb2pdu.c | 13 ++++++++-----
> >> 1 file changed, 8 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> >> index 1b906de..78b329f 100644
> >> --- a/fs/cifs/smb2pdu.c
> >> +++ b/fs/cifs/smb2pdu.c
> >> @@ -1218,7 +1218,7 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon *tcon, u64 persistent_fid,
> >> struct smb2_ioctl_req *req;
> >> struct smb2_ioctl_rsp *rsp;
> >> struct TCP_Server_Info *server;
> >> - struct cifs_ses *ses = tcon->ses;
> >> + struct cifs_ses *ses;
> >> struct kvec iov[2];
> >> int resp_buftype;
> >> int num_iovecs;
> >> @@ -1233,6 +1233,11 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon *tcon, u64 persistent_fid,
> >> if (plen)
> >> *plen = 0;
> >>
> >> + if (tcon)
> >> + ses = tcon->ses;
> >> + else
> >> + return -EIO;
> >> +
> >> if (ses && (ses->server))
> >> server = ses->server;
> >> else
> >> @@ -1296,14 +1301,12 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon *tcon, u64 persistent_fid,
> >> rsp = (struct smb2_ioctl_rsp *)iov[0].iov_base;
> >>
> >> if ((rc != 0) && (rc != -EINVAL)) {
> >> - if (tcon)
> >> - cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
> >> + cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
> >> goto ioctl_exit;
> >> } else if (rc == -EINVAL) {
> >> if ((opcode != FSCTL_SRV_COPYCHUNK_WRITE) &&
> >> (opcode != FSCTL_SRV_COPYCHUNK)) {
> >> - if (tcon)
> >> - cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
> >> + cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
> >> goto ioctl_exit;
> >> }
> >> }
> >
> >
>
>
>
--
Jeff Layton <jlayton@samba.org>
next prev parent reply other threads:[~2015-04-01 11:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-27 5:27 [PATCH 0/4] Fix various coverity warnings in fs/cifs Steve French
2015-03-27 5:27 ` [PATCH 1/4] [SMB3] Fix warning on uninitialized buftype Steve French
[not found] ` <1427434082-4299-2-git-send-email-smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-03-28 14:19 ` Shirish Pargaonkar
2015-03-30 9:36 ` Sachin Prabhu
2015-04-01 0:35 ` Jeff Layton
2015-03-27 5:28 ` [PATCH 2/4] [CIFS] Don't ignore errors on encrypting password in SMBTcon Steve French
[not found] ` <1427434082-4299-3-git-send-email-smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-03-28 14:26 ` Shirish Pargaonkar
2015-03-30 9:44 ` Sachin Prabhu
2015-04-01 0:37 ` Jeff Layton
[not found] ` <1427434082-4299-1-git-send-email-smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-03-27 5:28 ` [PATCH 3/4] [SMB3] Fix dereference before null check warning Steve French
[not found] ` <1427434082-4299-4-git-send-email-smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-03-28 14:27 ` Shirish Pargaonkar
2015-03-30 9:50 ` Sachin Prabhu
2015-04-01 0:46 ` Jeff Layton
2015-04-01 5:00 ` Steve French
2015-04-01 11:07 ` Jeff Layton [this message]
2015-03-27 5:28 ` [PATCH 4/4] [SMB3] Fix coverity warning Steve French
2015-03-28 15:05 ` Shirish Pargaonkar
2015-03-30 9:51 ` Sachin Prabhu
[not found] ` <1427434082-4299-5-git-send-email-smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-04-01 0:38 ` Jeff Layton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150401070700.268628b2@tlielax.poochiereds.net \
--to=jlayton@samba.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=smfrench@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox