On Tue, Nov 10, 2020 at 03:34:05PM +0000, Colin Ian King wrote:
> On 10/11/2020 15:24, Paul E. McKenney wrote:
> > 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@xxxxxxxxxxxxx>
> >>>>
> >>>> 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? ;-)
>
> For me, part of the QA process is statically analyzing linux-next to
> catch bugs before they land in linux. I think other testing is equally
> worth while as catching bugs early saves time and money.
All kidding aside, the fact that this appeared in -next was due to a
mistake on my part, namely failing to push the changes before starting
the test. Please accept my apologies, and I will continue to do my
best to avoid this sort of thing.
Thanx, Paul
> Colin
>
> >
> >> Thanks,
> >> Paul.
> >> --
> >>
> >>>
> >>>> Signed-off-by: Colin Ian King <colin.king@xxxxxxxxxxxxx>
> >>>> ---
> >>>> 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")) {
> >>>
>
