lkml.org 
[lkml]   [2016]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: stable-security kernel updates
On Thu, Apr 21, 2016 at 04:13:07PM +0200, Jiri Slaby wrote:
> On 04/21/2016, 03:54 PM, Sasha Levin wrote:
> > On 04/21/2016 08:39 AM, Greg KH wrote:
> >> On Thu, Apr 21, 2016 at 02:05:41PM +0200, Jiri Slaby wrote:
> >>>> On 04/21/2016, 01:59 PM, Jiri Slaby wrote:
> >>>>>>>> (CVE-2016-2085) 613317b EVM: Use crypto_memneq() for digest comparisons
> >>>>>>
> >>>>>> Does not exist in the CVE database/is not confirmed yet AFAICS.
> >>>>
> >>>> And now I am looking at the patch and I remember why I threw it away.
> >>>> crypto_memneq is not in 3.12 yet and I was not keen enough to backport it.
> >> Which brings up the question, Sasha, why did you think these CVEs were
> >> relevant for 3.12? What were you basing that list on?
> >
> > The EVM one? Because there exists a vulnerability in the 3.12 EVM code which
> > allows an attacker to essentially circumvent integrity checks, and the reason
> > it wasn't fixed was because a memory comparison helper function wasn't backported?
>
> Because sometimes the breakage risk is much higher than fixing a bug.
> This one was evaluated for 3.12.55 and not included at that time for
> that very reason.
>
> Now, given it it upstream for much longer, I reevaluated that and put
> that into the 3.12 tree.
>
> > For the other CVEs I've listed? I looked at what went in to 3.14 but not 3.12,
> > and audited the resulting list to confirm that the vulnerability existed on 3.12.
>
> Where exactly is 0185604 and 096fe9e contained in 3.14? I actually don't
> see them in any of Greg's stable tree.

Indeed, the first one was brought into 3.2 and 3.18 (so it's missing from
3.4 to 3.14), and the second one is in 3.18.

Willy

\
 
 \ /
  Last update: 2016-04-21 16:21    [W:0.852 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site