Subject: Re: stable-security kernel updates
To: Jiri Slaby <jslaby@suse.cz>, LKML <linux-kernel@vger.kernel.org>,
        stable <stable@vger.kernel.org>
References: <5717DD8A.4000707@oracle.com> <571876AB.2060106@suse.cz>
 <5718B57D.4000504@oracle.com> <5718C0B8.8010609@suse.cz>
Cc: lwn@lwn.net
From: Sasha Levin <sasha.levin@oracle.com>
Message-ID: <5718DB3F.5020107@oracle.com>
Date: Thu, 21 Apr 2016 09:53:03 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <5718C0B8.8010609@suse.cz>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="BVc5Vs31ojV7oe9AUxdglTb5mlGtGlW3I"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 7512
Lines: 210

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--BVc5Vs31ojV7oe9AUxdglTb5mlGtGlW3I
Content-Type: multipart/mixed; boundary="hCmOMlhMlISQO9meIU5E218j0FdSlwJCu"
From: Sasha Levin <sasha.levin@oracle.com>
To: Jiri Slaby <jslaby@suse.cz>, LKML <linux-kernel@vger.kernel.org>,
 stable <stable@vger.kernel.org>
Cc: lwn@lwn.net
Message-ID: <5718DB3F.5020107@oracle.com>
Subject: Re: stable-security kernel updates
References: <5717DD8A.4000707@oracle.com> <571876AB.2060106@suse.cz>
 <5718B57D.4000504@oracle.com> <5718C0B8.8010609@suse.cz>
In-Reply-To: <5718C0B8.8010609@suse.cz>

--hCmOMlhMlISQO9meIU5E218j0FdSlwJCu
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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?
>=20
> Any (write > 100) to "/sys/.../fw_update" writes '0' out of bounds, I
> suppose.
>=20
> 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.
>=20
>>> Input: powermate - fix oops with malicious USB descriptors
>>
>> This requires physical access to the machine.
>=20
> 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.
>=20
>>> rapidio/rionet: fix deadlock on SMP
>>
>> Seemed a bit borderline I suppose. There's nothing specific the
>> user can do to actually trigger this?
>=20
> Given my experience with fuzzers and bug hunting, how is not just heavy=

> loading the machine sufficient?
>=20
> Pardom my ignorance, how can you actually be sure?

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

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 securi=
ty
>> 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=
=2E
>=20
> 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 ev=
en
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 b=
etween
those updates.

>> So I've also ended up auditing the 3.12 for missing CVE fixes and thes=
e
>> 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)?
>=20
> 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 b=
y
> 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 bi=
g
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 fa=
lse
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:
>=20
>> (CVE-2015-7513) 0185604 KVM: x86: Reload pit counters for all channels=
 when restoring state
>=20
> This was not evaluated for SLE12 yet.

This is an almost half a year old vulnerability that allows guests to cra=
sh
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 c=
ritical
issues, then why bother at all?

>> (CVE-2015-8539) 096fe9e KEYS: Fix handling of stored error in a negati=
vely instantiated user key
>=20
> Backported now. Thanks for noting.
>=20
>> (CVE-2016-2085) 613317b EVM: Use crypto_memneq() for digest comparison=
s
>=20
> 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?
>=20
> 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


--hCmOMlhMlISQO9meIU5E218j0FdSlwJCu--

--BVc5Vs31ojV7oe9AUxdglTb5mlGtGlW3I
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXGNtAAAoJEN6mb/eXdyzcp3UP/0+JGNTg7dw3He5Hrm+BhbjU
5F16RQENz1LONeFB4ORHiWBhLmLSBYHkTiRXHh+iTtVLDzjogXtaSk9HVkjOfkR9
y3+8Q8W2IiYq+92pAX90i71MC+37qY1bqphWBvDFusUFK8dAmj9d5A3vLe4qByW+
cu3MsXA06WinDYxuYSEevjseVB1kN0Ug/1EMS4JOPVa1mnQYiGcxqXqRjyNEmsUk
PS253INiak5WQiFzKnxE+yoMnG2EBB69nBcSB3Xl9gAs8wGhFZ8BdChkZneTTVeq
nOfnVMsrAVmI0wecNnu4xo9yLR5hNW2ZvC2uooaFB9j8pF047bD9JXdzPDDJGIVZ
kQD87k4j9GtMEJG1bOCcP+Vhw5siEKpCZLaj3zmiHGuO/jTuOiVOeMFcuAz35YSk
tMvtKzHeVWJRAMbU/WhMxnKQqOLR4+yJbMph0KQ2OtrrwlNhoB5+IK5lQxBwAvzD
7P0YQvBoEqDuOspU9Rk5m/LxQvDVQsXLfO/6J8wHVFv3C4f/5n77Qw4aFWYXGIS3
M8CPHKjDG/pVY6jnQuQ8jjAvFT4+Ry/ddVJr3OvXVkCqy6p/LeG4i528qbRKpHsR
hihxoY0qSf/NMgNQTnbjOf+kXtgYbh3AxCFX1hk11EnT/gmWTllGKrz2wIEfyyyW
ZyNgQaKJSsJ9uFqMDFaJ
=Yb29
-----END PGP SIGNATURE-----

--BVc5Vs31ojV7oe9AUxdglTb5mlGtGlW3I--