Re: CVE-2017-15102: Linux kernel: usb: NULL-deref due to a race condition in [legousbtower] driver

[Eddie Chapman <eddie () ehuk net>]

On 14/11/17 12:32, Brad Spengler wrote:
> Hi Greg,
>
> We're all aware of your objection, you bring it up every time
> anyone mentions Linux kernel security on this list.  However,
> please remember that all the people contributing on this list are
> taking on the responsiblity you and the majority of other upstream
> developers have abdicated.

Does Linus, Greg, Al, etc, etc, etc owe anyone anything? Yes, they're 
time is paid by companies and/or the Linux Foundation, but do those orgs 
have a responsibility to anyone? They're working incredibly hard on 
probably one of the most difficult project management feats anyone could 
attempt, which anyone can take the end results of, and use without 
monetary cost. Linus has the right to treat security in whatever way he 
wishes to, according to his own personal philosophy, ultimately it is 
his project and he answers to no-one other than himself.

You say everyone on this list is taking on this "responsibility". So 
what? Some are making a living or business out of that. Maybe it is 
right that the "community" sifts through all the bug fixes and 
identifies issues that have a security impact. Kernel development is 
hard enough, someone committing a fix has already done a lot of work. Do 
they have an obligation to do the extra thinking and documenting in the 
commit log in order to identify how someone might maliciously take 
advantage of a flaw? It seems we have a whole industry of people who are 
good at that, so why shouldn't that industry take on that task? Would 
you, Brad, be in business with your product if the kernel people handled 
security perfectly? I have nothing against grsecurity and your efforts, 
I see no harm in companies making a business out of kernel security.

> Vladis' original mail made it clear the bug was
> already fixed with the included upstream fix link, so your
> follow-up was unnecessary.

I don't see a problem on this list with too many people making 
unnecessary, frivolous contributions. If you feel your rant was worthy 
of being posted, then I'd say Greg's comments, which were polite and 
without a hint of vitriol, were also worthy of contribution. I think you 
should leave it up to the moderator who does a good job of supervising 
this list, rather than suggesting that anyone's comments are unnecessary.

> If you truly believe there is no uniqueness to security bugs, I
> would advise you to shut down security () kernel org.

Regardless of what anyone at the top of the kernel project may have said 
in the past, I think the reality shows that kernel people on the whole 
take security relatively seriously. After all, nearly everyone involved 
is a user as well as a developer, and I don't think any of them would 
seriously claim to not have any concerns about their own boxen getting 
compromised. Yes, there is room for improvement, and reaction to 
individual security issues can be debated, but it is unfair to 
characterise the kernel community as not caring at all about security. 
Personally I see a lot of examples of kernel people genuinely making 
efforts to make the kernel more secure, and very few (by comparison), 
isolated cases of issues being dismissed, or security impact being 
downplayed. I'm sure examples can be dragged up from the past involving 
prominent people.  But I've seen plenty of evidence of a genuine desire 
(even on the part of Linus himself, in what he writes in commit logs) to 
make the kernel more secure, not less.

>  I would also
> ask that you come up with a better solution to the problem than
> demanding people run the latest version of Linux. According to my
> current records someone taking that advice would be exposed to a
> bug that can brick systems that seems nowhere close to resolution,
> and one that makes it impossible to run KVM guests on AMD (which went
> unfixed for 3 months, and the current fix isn't cc'd for stable --
> makes me wonder how much testing -rc really gets).

Regardless of what anyone might *say*, the reality is that there is no 
reason for anyone to feel compelled to run the very latest kernel in 
order to stay secure. The list of kernels receiving regular backported 
fixes is frankly more than is really needed. Greg himself goes above and 
beyond in this regard and works incredibly hard in maintaining, at the 
time of writing, 3.18 (unofficially), 4.4, 4.9, and 4.13, usually with 2 
or 3 releases a month each. All branches have well defined projected EOL 
dates. If that is not enough, there are other people actively 
maintaining 3.2, 3.10 (though just became EOL), 3.16 and 4.1! And that 
is just the vanilla kernels, when you factor in distro kernels with 
their own kernel teams backporting security fixes, the choice of secure 
kernels to run is incredible, we've never had it so good.

> You might want to focus your time on getting your own house in
> order instead of constantly pestering the people on this list -- we
> work in the trenches and aren't swayed by nonsense arguments that
> have no viable solution attached.

I think the kernel community can hardly be characterised as needing to 
put its "house in order", that is a gross exaggeration. It's not perfect 
and improvemets are needed. I welcome the efforts Greg is making to 
improve things, and his efforts to participate here, and I certainly 
don't think Brad speaks for everyone, at least not for me.

Eddie

> Thanks,
> -Brad
>
> On Tue, Nov 14, 2017 at 08:37:20AM +0100, Greg KH wrote:
> > On Mon, Nov 13, 2017 at 07:42:27PM -0500, David A. Wheeler wrote:
> > > On Mon, 13 Nov 2017 16:15:24 +0100, Greg KH <greg () kroah com> wrote:
> > > > It's the arbitrarily nature here that I am curious about, it feels like
> > > > it should be "all or nothing", for CVEs to mean much here.  Right now it
> > > > seems like it is just, "all that we care to track"?  :)
> > >
> > > "All" would be awesome, though unlikely.  But even if that's the eventual goal,
> > > "good starts" are still good starts.
> >
> > But really, this isn't even a "good start", it's identifying a bug fixed
> > over a year ago for a kernel that only one company seems to care about
> > because they are _not_ following the recommended upstream stable kernel
> > patches because they "know better" :)
> >
> > That's my objection here.
> >
> > thanks,
> >
> > greg k-h