From: "Paul E. McKenney" <paulmck@kernel.org>
To: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Qian Cai <cai@redhat.com>, Colin King <colin.king@canonical.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: [PATCH][next] cpumask: allocate enough space for string and trailing '\0' char
Date: Tue, 10 Nov 2020 07:24:37 -0800 [thread overview]
Message-ID: <20201110152437.GS3249@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <e0458a3f-7635-bc80-9496-731bdfceed0d@windriver.com>
On Mon, Nov 09, 2020 at 11:57:15PM -0500, Paul Gortmaker wrote:
>
>
> On 2020-11-09 8:07 p.m., Qian Cai wrote:
> > On Mon, 2020-11-09 at 13:04 +0000, Colin King wrote:
> > > From: Colin Ian King <colin.king@canonical.com>
> > >
> > > Currently the allocation of cpulist is based on the length of buf but does
> > > not include the addition end of string '\0' terminator. Static analysis is
> > > reporting this as a potential out-of-bounds access on cpulist. Fix this by
> > > allocating enough space for the additional '\0' terminator.
> > >
> > > Addresses-Coverity: ("Out-of-bounds access")
> > > Fixes: 65987e67f7ff ("cpumask: add "last" alias for cpu list specifications")
> >
> > Yeah, this bad commit also introduced KASAN errors everywhere and then will
> > disable lockdep that makes our linux-next CI miserable. Confirmed that this
> > patch will fix it.
>
> I appreciate the reports reminding me why I hate touching string handling.
>
> But let us not lose sight of why linux-next exists. We want to
> encourage code to appear there as a sounding board before it goes
> mainline, so we can fix things and not pollute mainline git history
> with those trivialities.
>
> If you've decided to internalize linux-next as part of your CI, then
> great, but do note that does not elevate linux-next to some pristine
> status for the world at large. That only means you have to watch more
> closely what is going on.
>
> If you want to declare linux-next unbreakable -- well that would scare
> away others to get the multi-arch or multi-config coverage that they may
> not be able to do themselves. We are not going to do that.
>
> I have (hopefully) fixed the "bad commit" in v2 -- as part of the
> implicit linux-next rule "you broke it, you better fix it ASAP".
>
> But "bad" and "miserable" can be things that might scare people off of
> making use of linux-next for what it is meant to be for. And I am not
> OK with that.
They would need to use much stronger language to scare me off. That said,
what on earth is the point of running tests if they do not from time to
time find bugs? ;-)
Thanx, Paul
> Thanks,
> Paul.
> --
>
> >
> > > Signed-off-by: Colin Ian King <colin.king@canonical.com>
> > > ---
> > > lib/cpumask.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/lib/cpumask.c b/lib/cpumask.c
> > > index 34ecb3005941..cb8a3ef0e73e 100644
> > > --- a/lib/cpumask.c
> > > +++ b/lib/cpumask.c
> > > @@ -185,7 +185,7 @@ int __ref cpulist_parse(const char *buf, struct cpumask
> > > *dstp)
> > > {
> > > int r;
> > > char *cpulist, last_cpu[5]; /* NR_CPUS <= 9999 */
> > > - size_t len = strlen(buf);
> > > + size_t len = strlen(buf) + 1;
> > > bool early = !slab_is_available();
> > > if (!strcmp(buf, "all")) {
> >
next prev parent reply other threads:[~2020-11-10 15:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20201109130447.2080491-1-colin.king@canonical.com>
2020-11-10 1:07 ` [PATCH][next] cpumask: allocate enough space for string and trailing '\0' char Qian Cai
2020-11-10 4:57 ` Paul Gortmaker
2020-11-10 15:24 ` Paul E. McKenney [this message]
2020-11-10 15:34 ` Colin Ian King
2020-11-10 18:38 ` Paul E. McKenney
2020-11-10 19:07 ` Colin Ian King
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=20201110152437.GS3249@paulmck-ThinkPad-P72 \
--to=paulmck@kernel.org \
--cc=cai@redhat.com \
--cc=colin.king@canonical.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=sfr@canb.auug.org.au \
/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