Re: stable-security kernel updates

[Sasha Levin]

On 04/21/2016 07:59 AM, Jiri Slaby wrote:
> On 04/21/2016, 01:11 PM, Sasha Levin wrote:
>>> Ok, not that bad, it is only unused code, but why are *not* these in the
>>> security tree?
>>> ipr: Fix out-of-bounds null overwrite
>>
>> Is there a particular way to exploit this that I'm missing?
> 
> Any (write > 100) to "/sys/.../fw_update" writes '0' out of bounds, I
> suppose.
> 
> But the point is different: I don't even need to care if there is one.
> And more, I don't even want to wait for one to appear.
> 
>>> Input: powermate - fix oops with malicious USB descriptors
>>
>> This requires physical access to the machine.
> 
> This is no relevant argument. There are plenty of studying rooms with
> computers and I don't want users to crash a machine by a buggy driver.
> OK, in this particular case, a broken cable, buggy bus or FW bug or
> whatever would be needed on the top of that. But I am not a god to know
> the circumstances before they occur, so better be safe now as it's
> clearly a bugfix.
> 
>>> rapidio/rionet: fix deadlock on SMP
>>
>> Seemed a bit borderline I suppose. There's nothing specific the
>> user can do to actually trigger this?
> 
> Given my experience with fuzzers and bug hunting, how is not just heavy
> loading the machine sufficient?
> 
> Pardom my ignorance, how can you actually be sure?

I'm not, same way you can't be sure about your stable patch selection either.

A commit that may not look to you like stable material might turn out to be one,
so how is this different for stable-security?

>> Another thing to note here is that security patch selection database
>> is shared between versions, so if a given commit gets marked as security
>> later on (someone figured out it's a CVE or something similar), it'll
>> get added to the stable-security tree even if it was initially skipped.
> 
> But that's too late. You then have to force people update immediately
> while you actually would not need to.

"immediately" is a strong word. Right now they won't update at all, so even
if they take a month to update that's better than the current state.

I'm not trying to replace the stable trees, I'm trying to help users who don't
update the stable tree that often to at least receive critical fixes in between
those updates.

>> So I've also ended up auditing the 3.12 for missing CVE fixes and these
>> ones ended up being at the top of the list. Could you explain why they
>> are not in the 3.12 stable tree (and as a result can't get to users of
>> the corresponding stable-security tree)?
> 
> Sure. They didn't apply or were not marked as stable. In both cases it
> is the code maintainer responsibility to take care of those. At least by
> pinging the stable list with SHAs.

Given this, how can you tell people they should be using your stable tree
rather than updating the kernel as a whole? The 3.12 tree is missing a big
chunk of commits that are stable material even though they weren't tagged
as such.

Those commits fix real bugs and by not shipping them users are given a false
sense of security by just updating the stable tree rather than the entire
kernel tree.

> On the top of that, I monitor SLE12 changes and:
> 
>> (CVE-2015-7513) 0185604 KVM: x86: Reload pit counters for all channels when restoring state
> 
> This was not evaluated for SLE12 yet.

This is an almost half a year old vulnerability that allows guests to crash
KVM hosts; something I'd consider quite critical these days.

This sort of thing is something that might encourage users not to follow the
stable tree at all. If updating the stable tree won't fix these sort of critical
issues, then why bother at all?

>> (CVE-2015-8539) 096fe9e KEYS: Fix handling of stored error in a negatively instantiated user key
> 
> Backported now. Thanks for noting.
> 
>> (CVE-2016-2085) 613317b EVM: Use crypto_memneq() for digest comparisons
> 
> Does not exist in the CVE database/is not confirmed yet AFAICS.

I saw it being shipped in Ubuntu kernels at the beginning of the month
with that CVE tag. Not sure about how that works though.

Ignoring the CVE stuff, this is a very serious issue and has a fix
that was supposed to make it to users of the stable tree. Why didn't it?

>> So while the stable-security tree might be missing commits that might
>> or might not have security impact, it seems the 3.12 tree itself is
>> missing fixes for privilege escalation CVEs from last year. Should I
>> be recommending that no one uses 3.12?
> 
> First, I am not deliberately filtering commits on an invalid basis.

I'd be happy to set clearer guidelines for what I consider a security
fix if that's the concern here?

> Second, every fart can have a CVE number today. CVE number should be by
> no means used as a decision.

Agreed, but it's safe to assume that anything with a CVE tag is worth
looking at. I don't think I've listed any "farts" above.

> Third, whatever is missing and is applicable, I am putting in.

Same for the stable-security tree. If you see anything I've missed please
let me know and I'll include it.

> Fourth, naturally, there is a lot of patches missing in the net flowing
> in the large sea of patches. But given your count of patches, you have ~
> 2 times higher chance to miss something important.

I do? Per the definition of stable-security, I only have to select them
from the ones you already selected. So while I have to look through ~50
commits per version you need to look at hundreds.

You're way more likely than me to miss a commit that was supposed to be
in stable, than me missing something that had to go into stable-security.


Thanks,
Sasha

Attachment: signature.asc
Description: OpenPGP digital signature