Date:	Thu, 21 Apr 2016 13:59:52 +0200
From:	Jiri Slaby <jslaby@...e.cz>
To:	Sasha Levin <sasha.levin@...cle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	stable <stable@...r.kernel.org>
Cc:	lwn@....net
Subject: Re: stable-security kernel updates

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?

> 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.

> 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.

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.

> (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.

> 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.

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

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

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.

thanks,
-- 
js
suse labs



Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists