From: Dan Carpenter <dan.carpenter@oracle.com>
To: Tigran Aivazian <aivazian.tigran@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] bfs: prevent underflow in bfs_find_entry()
Date: Tue, 10 Mar 2020 08:38:16 +0000 [thread overview]
Message-ID: <20200310083816.GA11561@kadam> (raw)
In-Reply-To: <CAK+_RLm9=DER3fM-HwvM14CEzq8eZCwcTZyoA6tsYdhe1J03sA@mail.gmail.com>
On Mon, Mar 09, 2020 at 09:14:27AM +0000, Tigran Aivazian wrote:
> Hello Dan,
>
> On Sat, 7 Mar 2020 at 06:08, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > - int namelen = child->len;
> > + unsigned int namelen = child->len;
>
> Thank you, that is sensible, but have you actually verified that
> attempting a lookup of a filename longer than 2.2 billion bytes causes
> a problem? If that's the case, then your patch should be considered.
> If not, it would seem to be a waste of time to worry about something
> that cannot ever happen.
As the commit message says, this is just to silence a static checker
warning about checking for upper bounds but ignoring negatives. The
check has found a number of problems in the past but it becomes less
useful if security reviewers have to sort through a bunch of false
positives.
regards,
dan carpenter
WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Tigran Aivazian <aivazian.tigran@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] bfs: prevent underflow in bfs_find_entry()
Date: Tue, 10 Mar 2020 11:38:16 +0300 [thread overview]
Message-ID: <20200310083816.GA11561@kadam> (raw)
In-Reply-To: <CAK+_RLm9=DER3fM-HwvM14CEzq8eZCwcTZyoA6tsYdhe1J03sA@mail.gmail.com>
On Mon, Mar 09, 2020 at 09:14:27AM +0000, Tigran Aivazian wrote:
> Hello Dan,
>
> On Sat, 7 Mar 2020 at 06:08, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > - int namelen = child->len;
> > + unsigned int namelen = child->len;
>
> Thank you, that is sensible, but have you actually verified that
> attempting a lookup of a filename longer than 2.2 billion bytes causes
> a problem? If that's the case, then your patch should be considered.
> If not, it would seem to be a waste of time to worry about something
> that cannot ever happen.
As the commit message says, this is just to silence a static checker
warning about checking for upper bounds but ignoring negatives. The
check has found a number of problems in the past but it becomes less
useful if security reviewers have to sort through a bunch of false
positives.
regards,
dan carpenter
next prev parent reply other threads:[~2020-03-10 8:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-07 6:08 [PATCH] bfs: prevent underflow in bfs_find_entry() Dan Carpenter
2020-03-07 6:08 ` Dan Carpenter
2020-03-09 8:40 ` AW: " Walter Harms
2020-03-09 8:40 ` Walter Harms
2020-03-10 9:06 ` Dan Carpenter
2020-03-10 9:06 ` Dan Carpenter
2020-03-10 17:57 ` AW: " Walter Harms
2020-03-10 18:22 ` Tigran Aivazian
2020-03-09 9:14 ` Tigran Aivazian
2020-03-09 9:14 ` Tigran Aivazian
2020-03-10 8:38 ` Dan Carpenter [this message]
2020-03-10 8:38 ` 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=20200310083816.GA11561@kadam \
--to=dan.carpenter@oracle.com \
--cc=aivazian.tigran@gmail.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.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.