From: Dan Carpenter <dan.carpenter@oracle.com>
To: Sudeep Dutt <sudeep.dutt@intel.com>
Cc: Nikhil Rao <nikhil.rao@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch 2/2] misc: mic/scif: fix wrap around tests
Date: Tue, 13 Oct 2015 15:51:35 +0300 [thread overview]
Message-ID: <20151013125135.GN7289@mwanda> (raw)
In-Reply-To: <1444554884.93285.233.camel@localhost>
On Sun, Oct 11, 2015 at 02:14:44AM -0700, Sudeep Dutt wrote:
> On Fri, 2015-10-09 at 09:40 +0300, Dan Carpenter wrote:
> > Signed integer overflow is undefined. Also I added a check for
> > "(offset < 0)" in scif_unregister() because that makes it match the
> > other conditions and because I didn't want to subtract a negative.
> >
> > Fixes: ba612aa8b487 ('misc: mic: SCIF memory registration and unregistration')
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > ---
> >
> > Imagine you are on 64 bit and len is larger than INT_MAX << 12, it means
> > that we truncate it because scif_get_window_offset() takes an integer
> > argument. I don't know if this is an issue.
>
> scif_get_window_offset(..) takes an integer argument for the number of
> pages. We believe that an int for number of 4K pages is sufficient for
> current systems. I don't think there is an issue here.
The issue isn't that we need more pages, it's that we can overflow
INT_MAX so scif_get_window_offset() succeeds when it should fail.
>
> > Maybe I should use
> > INT_MAX instead of LONG_MAX? I am working on a static checker warning
> > for these types of issues:
> > drivers/misc/mic/scif/scif_rma.c:1631 scif_register() warn: truncating user data 'len >> 12' '0-4503599627370495'
> > drivers/misc/mic/scif/scif_rma.c:1643 scif_register() warn: truncating user data 'len >> 12' '0-4503599627370495'
> >
> > The other static warnings here are:
> >
> > drivers/misc/mic/scif/scif_rma.c:745 scif_unregister_window() warn: inconsistent returns 'mutex:&ep->rma_info.rma_lock'.
> > Locked on: line 745
> > Unlocked on: line 687
>
> The function expects the lock to be held by the caller so there is no
> issue here.
>
You're missing the point. Never mind, I will send a patch for this.
> > @@ -1613,7 +1613,7 @@ off_t scif_register(scif_epd_t epd, void *addr, size_t len, off_t offset,
> > if ((map_flags & SCIF_MAP_FIXED) &&
> > ((ALIGN(offset, PAGE_SIZE) != offset) ||
> > (offset < 0) ||
> > - (offset + (off_t)len < offset)))
> > + (len < LONG_MAX - offset)))
>
> Why is this change required? The earlier code was being used to detect
> wraparound and I think it works fine.
It doesn't work. off_t is a signed type so it's undefined. The
compiler will often just remove the condition.
regards,
dan carpenter
next prev parent reply other threads:[~2015-10-13 12:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-09 6:40 [patch 2/2] misc: mic/scif: fix wrap around tests Dan Carpenter
2015-10-11 9:14 ` Sudeep Dutt
2015-10-13 12:51 ` Dan Carpenter [this message]
2015-10-14 3:21 ` Sudeep Dutt
2015-10-14 18:05 ` 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=20151013125135.GN7289@mwanda \
--to=dan.carpenter@oracle.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nikhil.rao@intel.com \
--cc=sudeep.dutt@intel.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;
as well as URLs for NNTP newsgroup(s).