From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753169AbbDAFBW (ORCPT ); Wed, 1 Apr 2015 01:01:22 -0400 Received: from mail-lb0-f171.google.com ([209.85.217.171]:33118 "EHLO mail-lb0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750880AbbDAFBU (ORCPT ); Wed, 1 Apr 2015 01:01:20 -0400 MIME-Version: 1.0 In-Reply-To: <20150331204634.4d38c27e@synchrony.poochiereds.net> References: <1427434082-4299-1-git-send-email-smfrench@gmail.com> <1427434082-4299-4-git-send-email-smfrench@gmail.com> <20150331204634.4d38c27e@synchrony.poochiereds.net> From: Steve French Date: Wed, 1 Apr 2015 00:00:57 -0500 Message-ID: Subject: Re: [PATCH 3/4] [SMB3] Fix dereference before null check warning To: Jeff Layton Cc: "linux-cifs@vger.kernel.org" , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 31, 2015 at 7:46 PM, Jeff Layton wrote: > On Fri, 27 Mar 2015 00:28:01 -0500 > Steve French 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 > > 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. >> --- >> 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; >> } >> } > > -- Thanks, Steve