stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Slaby <jslaby@suse.cz>
To: Sasha Levin <sasha.levin@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>
Cc: lwn@lwn.net
Subject: Re: stable-security kernel updates
Date: Thu, 21 Apr 2016 13:59:52 +0200	[thread overview]
Message-ID: <5718C0B8.8010609@suse.cz> (raw)
In-Reply-To: <5718B57D.4000504@oracle.com>


[-- Attachment #1.1: Type: text/plain, Size: 3344 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-04-21 11:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20 19:50 stable-security kernel updates Sasha Levin
2016-04-21  6:43 ` Jiri Slaby
2016-04-21  7:11   ` Willy Tarreau
2016-04-21 11:27     ` Sasha Levin
2016-04-21 12:36       ` Greg KH
2016-04-21 14:01         ` Sasha Levin
2016-04-21 14:12           ` Willy Tarreau
2016-04-21 11:11   ` Sasha Levin
2016-04-21 11:59     ` Jiri Slaby [this message]
2016-04-21 12:05       ` Jiri Slaby
2016-04-21 12:39         ` Greg KH
2016-04-21 12:50           ` Willy Tarreau
2016-04-21 13:54           ` Sasha Levin
2016-04-21 14:13             ` Jiri Slaby
2016-04-21 14:19               ` Willy Tarreau
2016-04-21 14:27               ` Sasha Levin
2016-04-21 14:33                 ` Willy Tarreau
2016-04-25 23:14                   ` Ben Hutchings
2016-04-26  4:40                     ` Willy Tarreau
2016-04-21 13:53       ` Sasha Levin
2016-04-21 14:54         ` Jiri Slaby
2016-04-21 15:50           ` Sasha Levin
2016-04-21 19:32           ` Sasha Levin
2016-04-21 12:26     ` Bjørn Mork
2016-04-21 12:56 ` Willy Tarreau
2016-04-21 14:16   ` Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5718C0B8.8010609@suse.cz \
    --to=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lwn@lwn.net \
    --cc=sasha.levin@oracle.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).