All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Colin Ian King <colin.king@canonical.com>
Cc: Johannes Thumshirn <jth@kernel.org>,
	"James E . J . Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	fcoe-devel@open-fcoe.org, linux-scsi@vger.kernel.org,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] scsi: fcoe: sanity check string size for store_ctrl_mode option
Date: Thu, 23 Mar 2017 11:45:50 +0000	[thread overview]
Message-ID: <20170323114549.GN32449@mwanda> (raw)
In-Reply-To: <1b8384a7-9efe-7b93-e418-0f377bb84a73@canonical.com>

On Wed, Mar 22, 2017 at 07:42:08PM +0000, Colin Ian King wrote:
> On 22/03/17 19:39, Dan Carpenter wrote:
> > On Wed, Mar 22, 2017 at 02:01:37PM +0000, Colin King wrote:
> >> From: Colin Ian King <colin.king@canonical.com>
> >>
> >> Reading and writing to mode[count - 1] implies the count should not
> >> be less than 1 so add a sanity check for this.
> >>
> >> Detected with CoverityScan, CID#1357345 ("Overflowed array index write")
> >>
> >> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> > 
> > This is harmless, of course, but count can't be zero.  This is a sysfs
> > file so we test for zero size writes in sysfs_kf_write() and return
> > early.
> 
> Ah, thanks for pointing out that. I overlooked that detail.
> 

The only reason I know this stuff is because it's annotated in Smatch.
So I do this:

diff --git a/drivers/scsi/fcoe/fcoe_sysfs.c b/drivers/scsi/fcoe/fcoe_sysfs.c
index 9cf3d56296ab..c491ad8fb0a8 100644
--- a/drivers/scsi/fcoe/fcoe_sysfs.c
+++ b/drivers/scsi/fcoe/fcoe_sysfs.c
@@ -281,6 +281,7 @@ static ssize_t show_ctlr_mode(struct device *dev,
 			"%s\n", name);
 }
 
+#include "/home/dcarpenter/progs/smatch/devel/check_debug.h"
 static ssize_t store_ctlr_mode(struct device *dev,
 			       struct device_attribute *attr,
 			       const char *buf, size_t count)
@@ -288,6 +289,7 @@ static ssize_t store_ctlr_mode(struct device *dev,
 	struct fcoe_ctlr_device *ctlr = dev_to_ctlr(dev);
 	char mode[FCOE_MAX_MODENAME_LEN + 1];
 
+	__smatch_implied(count);
 	if (count > FCOE_MAX_MODENAME_LEN)
 		return -EINVAL;
 

Then when I run kchecker drivers/scsi/fcoe/fcoe_sysfs.c, it tells me:

drivers/scsi/fcoe/fcoe_sysfs.c:292 store_ctlr_mode() implied: count = '1-1000000000,2147479552'

Which is sort of surprising...  The 1000000000 value is a hack I made so
that it would never complain that "off + count" will wrap.  But
apparently something has changed so it's also picking up the true limit
of count which is 2147479552.

Then I run the following commands to view the call tree:
    smdb.py store_ctlr_mode
    smdb.py dev_attr_store
    smdb.py sysfs_kf_write
I have some vim macros so I can look these up really quickly.

regards,
dan carpenter

WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Colin Ian King <colin.king@canonical.com>
Cc: Johannes Thumshirn <jth@kernel.org>,
	"James E . J . Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	fcoe-devel@open-fcoe.org, linux-scsi@vger.kernel.org,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] scsi: fcoe: sanity check string size for store_ctrl_mode option
Date: Thu, 23 Mar 2017 14:45:50 +0300	[thread overview]
Message-ID: <20170323114549.GN32449@mwanda> (raw)
In-Reply-To: <1b8384a7-9efe-7b93-e418-0f377bb84a73@canonical.com>

On Wed, Mar 22, 2017 at 07:42:08PM +0000, Colin Ian King wrote:
> On 22/03/17 19:39, Dan Carpenter wrote:
> > On Wed, Mar 22, 2017 at 02:01:37PM +0000, Colin King wrote:
> >> From: Colin Ian King <colin.king@canonical.com>
> >>
> >> Reading and writing to mode[count - 1] implies the count should not
> >> be less than 1 so add a sanity check for this.
> >>
> >> Detected with CoverityScan, CID#1357345 ("Overflowed array index write")
> >>
> >> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> > 
> > This is harmless, of course, but count can't be zero.  This is a sysfs
> > file so we test for zero size writes in sysfs_kf_write() and return
> > early.
> 
> Ah, thanks for pointing out that. I overlooked that detail.
> 

The only reason I know this stuff is because it's annotated in Smatch.
So I do this:

diff --git a/drivers/scsi/fcoe/fcoe_sysfs.c b/drivers/scsi/fcoe/fcoe_sysfs.c
index 9cf3d56296ab..c491ad8fb0a8 100644
--- a/drivers/scsi/fcoe/fcoe_sysfs.c
+++ b/drivers/scsi/fcoe/fcoe_sysfs.c
@@ -281,6 +281,7 @@ static ssize_t show_ctlr_mode(struct device *dev,
 			"%s\n", name);
 }
 
+#include "/home/dcarpenter/progs/smatch/devel/check_debug.h"
 static ssize_t store_ctlr_mode(struct device *dev,
 			       struct device_attribute *attr,
 			       const char *buf, size_t count)
@@ -288,6 +289,7 @@ static ssize_t store_ctlr_mode(struct device *dev,
 	struct fcoe_ctlr_device *ctlr = dev_to_ctlr(dev);
 	char mode[FCOE_MAX_MODENAME_LEN + 1];
 
+	__smatch_implied(count);
 	if (count > FCOE_MAX_MODENAME_LEN)
 		return -EINVAL;
 

Then when I run kchecker drivers/scsi/fcoe/fcoe_sysfs.c, it tells me:

drivers/scsi/fcoe/fcoe_sysfs.c:292 store_ctlr_mode() implied: count = '1-1000000000,2147479552'

Which is sort of surprising...  The 1000000000 value is a hack I made so
that it would never complain that "off + count" will wrap.  But
apparently something has changed so it's also picking up the true limit
of count which is 2147479552.

Then I run the following commands to view the call tree:
    smdb.py store_ctlr_mode
    smdb.py dev_attr_store
    smdb.py sysfs_kf_write
I have some vim macros so I can look these up really quickly.

regards,
dan carpenter

  reply	other threads:[~2017-03-23 11:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-22 14:01 [PATCH] scsi: fcoe: sanity check string size for store_ctrl_mode option Colin King
2017-03-22 19:39 ` Dan Carpenter
2017-03-22 19:39   ` Dan Carpenter
2017-03-22 19:42   ` Colin Ian King
2017-03-23 11:45     ` Dan Carpenter [this message]
2017-03-23 11:45       ` Dan Carpenter

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=20170323114549.GN32449@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=colin.king@canonical.com \
    --cc=fcoe-devel@open-fcoe.org \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=jth@kernel.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.