All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Souptick Joarder <jrdr.linux@gmail.com>
Cc: "Kishon Vijay Abraham I" <kishon@ti.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Jon Mason" <jdmason@kudzu.us>, "Frank Li" <Frank.Li@nxp.com>,
	linux-pci@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 2/2] NTB: EPF: Tidy up some bounds checks
Date: Tue, 2 Aug 2022 14:01:33 +0300	[thread overview]
Message-ID: <20220802110133.GG3460@kadam> (raw)
In-Reply-To: <CAFqt6zaLY3_DKC-=NJSrgzePrDS-q-dfUQxrN9puBf0+qVNfUg@mail.gmail.com>

On Tue, Aug 02, 2022 at 04:19:33PM +0530, Souptick Joarder wrote:
> On Mon, Aug 1, 2022 at 3:47 PM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> >
> > This sscanf() is reading from the filename which was set by the kernel
> > so it should be trust worthy.  Although the data is likely trust worthy
> > there is some bounds checking but unfortunately, it is not complete or
> > consistent.  Additionally, the Smatch static checker marks everything
> > that comes from sscanf() as tainted and so Smatch complains that this
> > code can lead to an out of bounds issue.  Let's clean things up and make
> > Smatch happy.
> >
> > The first problem is that there is no bounds checking in the _show()
> > functions.  The _store() and _show() functions are very similar so make
> > the bounds checking the same in both.
> >
> > The second issue is that if "win_no" is zero it leads to an array
> > underflow so add an if (win_no <= 0) check for that.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > ---
> >  drivers/pci/endpoint/functions/pci-epf-vntb.c | 11 +++++++++--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/endpoint/functions/pci-epf-vntb.c b/drivers/pci/endpoint/functions/pci-epf-vntb.c
> > index cf338f3cf348..a7fe86f43739 100644
> > --- a/drivers/pci/endpoint/functions/pci-epf-vntb.c
> > +++ b/drivers/pci/endpoint/functions/pci-epf-vntb.c
> > @@ -831,9 +831,16 @@ static ssize_t epf_ntb_##_name##_show(struct config_item *item,            \
> >  {                                                                      \
> >         struct config_group *group = to_config_group(item);             \
> >         struct epf_ntb *ntb = to_epf_ntb(group);                        \
> > +       struct device *dev = &ntb->epf->dev;                            \
> >         int win_no;                                                     \
> >                                                                         \
> > -       sscanf(#_name, "mw%d", &win_no);                                \
> > +       if (sscanf(#_name, "mw%d", &win_no) != 1)                       \
> > +               return -EINVAL;                                         \
> > +                                                                       \
> > +       if (win_no <= 0 || win_no > ntb->num_mws) {                     \
> > +               dev_err(dev, "Invalid num_nws: %d value\n", ntb->num_mws); \
> > +               return -EINVAL;                                         \
> > +       }                                                               \
> >                                                                         \
> >         return sprintf(page, "%lld\n", ntb->mws_size[win_no - 1]);      \
> >  }
> > @@ -856,7 +863,7 @@ static ssize_t epf_ntb_##_name##_store(struct config_item *item,    \
> >         if (sscanf(#_name, "mw%d", &win_no) != 1)                       \
> >                 return -EINVAL;                                         \
> >                                                                         \
> > -       if (ntb->num_mws < win_no) {                                    \
> > +       if (win_no <= 0 || win_no > ntb->num_mws) {                     \
> 
> This might change the existing logic. will it be ?
> if (win_no <= 0 || win_no >= ntb->num_mws) {

No, it doesn't change the exiting logic with regards to the upper
bounds. if (foo > bar) is the same as if (bar < foo).  It just adds a
lower bounds check.

Normally, the variable part of the condition is on the right.  Check
patch enforces that rule where it can.  It's the same in English, the
variable comes first.  "If twelve foot is greater than the height of the
tree then blah blah" vs "if the tree is less than twelve foot blah
blah".

regards,
dan carpenter


  reply	other threads:[~2022-08-02 11:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-01 10:15 [PATCH 1/2] NTB: EPF: Fix error code in epf_ntb_bind() Dan Carpenter
2022-08-01 10:17 ` [PATCH 2/2] NTB: EPF: Tidy up some bounds checks Dan Carpenter
2022-08-02 10:49   ` Souptick Joarder
2022-08-02 11:01     ` Dan Carpenter [this message]
2022-08-02 11:20       ` Dan Carpenter
2022-08-02 11:32         ` Souptick Joarder
2022-08-02 10:16 ` [PATCH 1/2] NTB: EPF: Fix error code in epf_ntb_bind() Souptick Joarder
2022-08-12 14:16 ` Jon Mason

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=20220802110133.GG3460@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=Frank.Li@nxp.com \
    --cc=bhelgaas@google.com \
    --cc=jdmason@kudzu.us \
    --cc=jrdr.linux@gmail.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=kishon@ti.com \
    --cc=kw@linux.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    /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.