Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1383716 > unrolled thread

stable-security kernel updates

Back to article view | Back to linux.kernel

Contents

  stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-20 22:00 +0200
    Re: stable-security kernel updates Jiri Slaby <jslaby@suse.cz> - 2016-04-21 08:50 +0200
      Re: stable-security kernel updates Willy Tarreau <w@1wt.eu> - 2016-04-21 09:20 +0200
        Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 13:30 +0200
          Re: stable-security kernel updates Greg KH <greg@kroah.com> - 2016-04-21 14:40 +0200
            Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 16:10 +0200
              Re: stable-security kernel updates Willy Tarreau <w@1wt.eu> - 2016-04-21 16:20 +0200
      Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 13:20 +0200
        Re: stable-security kernel updates Jiri Slaby <jslaby@suse.cz> - 2016-04-21 14:10 +0200
          Re: stable-security kernel updates Greg KH <greg@kroah.com> - 2016-04-21 14:40 +0200
            Re: stable-security kernel updates Willy Tarreau <w@1wt.eu> - 2016-04-21 15:00 +0200
            Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 16:00 +0200
              Re: stable-security kernel updates Jiri Slaby <jslaby@suse.cz> - 2016-04-21 16:20 +0200
                Re: stable-security kernel updates Willy Tarreau <w@1wt.eu> - 2016-04-21 16:20 +0200
                Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 16:30 +0200
                  Re: stable-security kernel updates Willy Tarreau <w@1wt.eu> - 2016-04-21 16:40 +0200
                    Re: stable-security kernel updates Ben Hutchings <ben@decadent.org.uk> - 2016-04-26 01:20 +0200
                      Re: stable-security kernel updates Willy Tarreau <w@1wt.eu> - 2016-04-26 06:50 +0200
        Re: stable-security kernel updates Jiri Slaby <jslaby@suse.cz> - 2016-04-21 14:10 +0200
          Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 16:00 +0200
            Re: stable-security kernel updates Jiri Slaby <jslaby@suse.cz> - 2016-04-21 17:00 +0200
              Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 18:00 +0200
              Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 21:40 +0200
        Re: stable-security kernel updates Bjørn Mork <bjorn@mork.no> - 2016-04-21 14:30 +0200
    Re: stable-security kernel updates Willy Tarreau <w@1wt.eu> - 2016-04-21 15:00 +0200
      Re: stable-security kernel updates Sasha Levin <sasha.levin@oracle.com> - 2016-04-21 16:20 +0200

Page 1 of 2  [1] 2  Next page →

#1383716 — stable-security kernel updates

[Multipart message — attachments visible in raw view] — view raw

Hi all,

Updates for stable-security kernels have been released:

	- v3.12.58-security
	- v3.14.67-security
	- v3.18.31-security
	- v4.1.22-security
	- v4.4.8-security
	- v4.5.2-security

They are available at:

	https://git.kernel.org/cgit/linux/kernel/git/sashal/linux-stable-security.git/

Or:

	https://github.com/sashalevin/linux-stable-security


Thanks,
Sasha

[toc] | [next] | [standalone]

#1383890

[Multipart message — attachments visible in raw view] — view raw

On 04/20/2016, 09:50 PM, Sasha Levin wrote:
> Updates for stable-security kernels have been released:
> 
> 	- v3.12.58-security

I suggest nobody uses that kernel.

That tree does not make much sense to me. For example, what's the
purpose of "kernel: Provide READ_ONCE and ASSIGN_ONCE" (commit
230fa253df6352af12ad0a16128760b5cb3f92df upstream) without actually
using the added macros (this commit was only a prerequisite)?

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
Input: powermate - fix oops with malicious USB descriptors
rapidio/rionet: fix deadlock on SMP

thanks,
-- 
js
suse labs

[toc] | [prev] | [next] | [standalone]

#1383903

Hi Jiri,

On Thu, Apr 21, 2016 at 08:43:55AM +0200, Jiri Slaby wrote:
> On 04/20/2016, 09:50 PM, Sasha Levin wrote:
> > Updates for stable-security kernels have been released:
> > 
> > 	- v3.12.58-security
> 
> I suggest nobody uses that kernel.
> 
> That tree does not make much sense to me. For example, what's the
> purpose of "kernel: Provide READ_ONCE and ASSIGN_ONCE" (commit
> 230fa253df6352af12ad0a16128760b5cb3f92df upstream) without actually
> using the added macros (this commit was only a prerequisite)?
> 
> 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
> Input: powermate - fix oops with malicious USB descriptors
> rapidio/rionet: fix deadlock on SMP

This illustrates exactly what I suspected would happen because that's the
same trouble we all face when picking backports for our respective trees
except that since the selection barrier is much higher here, lots of
important ones will be missing.

Cheers,
Willy

[toc] | [prev] | [next] | [standalone]

#1384094

Hey Willy,

On 04/21/2016 03:11 AM, Willy Tarreau wrote:
> This illustrates exactly what I suspected would happen because that's the
> same trouble we all face when picking backports for our respective trees
> except that since the selection barrier is much higher here, lots of
> important ones will be missing

Right. I fully agree that there will be important security commits that'll
get missed, whether because they were missed in the stable selection or
the stable-security selection.

I'd like to point out again that updating the entire stable tree is the
preferable way to patch against security (and non-security) issues. The
stable-security tree is a best-effort solution to provide a stop-gap in
between said stable tree updates.


Thanks,
Sasha

[toc] | [prev] | [next] | [standalone]

#1384155

On Thu, Apr 21, 2016 at 07:27:39AM -0400, Sasha Levin wrote:
> Hey Willy,
> 
> On 04/21/2016 03:11 AM, Willy Tarreau wrote:
> > This illustrates exactly what I suspected would happen because that's the
> > same trouble we all face when picking backports for our respective trees
> > except that since the selection barrier is much higher here, lots of
> > important ones will be missing
> 
> Right. I fully agree that there will be important security commits that'll
> get missed, whether because they were missed in the stable selection or
> the stable-security selection.
> 
> I'd like to point out again that updating the entire stable tree is the
> preferable way to patch against security (and non-security) issues.

s/preferable/only/ :)

> The
> stable-security tree is a best-effort solution to provide a stop-gap in
> between said stable tree updates.

What are you "stop-gapping" then?  The 7-10 days between stable
releases?

confused,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1384270

On 04/21/2016 08:36 AM, Greg KH wrote:
> On Thu, Apr 21, 2016 at 07:27:39AM -0400, Sasha Levin wrote:
>> Hey Willy,
>>
>> On 04/21/2016 03:11 AM, Willy Tarreau wrote:
>>> This illustrates exactly what I suspected would happen because that's the
>>> same trouble we all face when picking backports for our respective trees
>>> except that since the selection barrier is much higher here, lots of
>>> important ones will be missing
>>
>> Right. I fully agree that there will be important security commits that'll
>> get missed, whether because they were missed in the stable selection or
>> the stable-security selection.
>>
>> I'd like to point out again that updating the entire stable tree is the
>> preferable way to patch against security (and non-security) issues.
> 
> s/preferable/only/ :)

Really? Even though as I showed updating your stable tree religiously would
still leave you vulnerable to "ancient" privesc exploits?

If anything, the *only* way is updating the entire kernel tree.

>> The
>> stable-security tree is a best-effort solution to provide a stop-gap in
>> between said stable tree updates.
> 
> What are you "stop-gapping" then?  The 7-10 days between stable
> releases?

In a perfect world where everyone has a team of kernel hackers on hand
reviewing stable commits, verifying the resulting kernel doesn't regress
their product, and fixes existing regressions for their product it might
be 7-10 days.

In the real world, this process takes much longer.

Doing a full rebase of the kernel tree is a much more costly process than
cherry picking a handful of security commits.


Thanks,
Sasha

[toc] | [prev] | [next] | [standalone]

#1384282

On Thu, Apr 21, 2016 at 10:01:29AM -0400, Sasha Levin wrote:
> > What are you "stop-gapping" then?  The 7-10 days between stable
> > releases?
> 
> In a perfect world where everyone has a team of kernel hackers on hand
> reviewing stable commits, verifying the resulting kernel doesn't regress
> their product, and fixes existing regressions for their product it might
> be 7-10 days.
> 
> In the real world, this process takes much longer.
> 
> Doing a full rebase of the kernel tree is a much more costly process than
> cherry picking a handful of security commits.

Usually what is being done is mostly to check the intersection areas
between local patches and the updated parts from the next kernel. I'm
not saying it doesn't take some time, I mean for most products, only
certain areas are being considered since you usually have lots of
"CONFIG_* is not set" in a product. It's totally different for a distro
however.

Regards,
Willy

[toc] | [prev] | [next] | [standalone]

#1384083

[Multipart message — attachments visible in raw view] — view raw

On 04/21/2016 02:43 AM, Jiri Slaby wrote:
> On 04/20/2016, 09:50 PM, Sasha Levin wrote:
>> Updates for stable-security kernels have been released:
>>
>> 	- v3.12.58-security
> 
> I suggest nobody uses that kernel.
> 
> That tree does not make much sense to me. For example, what's the
> purpose of "kernel: Provide READ_ONCE and ASSIGN_ONCE" (commit
> 230fa253df6352af12ad0a16128760b5cb3f92df upstream) without actually
> using the added macros (this commit was only a prerequisite)?

Looking at this, I believe that my scripts failed to merge the
follow up commit, and I missed that. I'll improve this so it won't
happen in the future. Thank you for this report.

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

> Input: powermate - fix oops with malicious USB descriptors

This requires physical access to the machine.

> rapidio/rionet: fix deadlock on SMP

Seemed a bit borderline I suppose. There's nothing specific the
user can do to actually trigger this?


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.


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)?

(CVE-2015-7513) 0185604 KVM: x86: Reload pit counters for all channels when restoring state
(CVE-2015-8539) 096fe9e KEYS: Fix handling of stored error in a negatively instantiated user key
(CVE-2016-2085) 613317b EVM: Use crypto_memneq() for digest comparisons

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?


Thanks,
Sasha

[toc] | [prev] | [next] | [standalone]

#1384131

[Multipart message — attachments visible in raw view] — view raw

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.

thanks,
-- 
js
suse labs

[toc] | [prev] | [next] | [standalone]

#1384153

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?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1384175

On Thu, Apr 21, 2016 at 09:39:18PM +0900, 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?

Yep same question here because in fact checking what is *missing* is
harder than checking what should not have been there. I'm pretty sure
I missed a lot of things in 2.6.32 (though Ben and Moritz helped a lot)
but precisely the fact that they provided me fixes I wasn't aware of is
a sign that I can miss things.
 
Any reliable process to check for missing fixes is welcome of course. For
now the best way I found is to pick from more recent stable versions, which
also ensures people upgrading from and older branch to a newer branch will
not find a bug they used to see fixed.

Cheers,
Willy

[toc] | [prev] | [next] | [standalone]

#1384266

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?

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.


Thanks,
Sasha

[toc] | [prev] | [next] | [standalone]

#1384275

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.

thanks,
-- 
js
suse labs

[toc] | [prev] | [next] | [standalone]

#1384278

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

[toc] | [prev] | [next] | [standalone]

#1384283

On 04/21/2016 10:13 AM, 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.

Okay, fair enough.

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

You're right, I looked at the 3.18 tree rather than 3.14, where there are:

8dc1d26 KVM: x86: Reload pit counters for all channels when restoring state
3fee639 KEYS: Fix handling of stored error in a negatively instantiated user key

This means that missing CVE fixes are quite common with stable trees?


Thanks,
Sasha

[toc] | [prev] | [next] | [standalone]

#1384288

On Thu, Apr 21, 2016 at 10:27:46AM -0400, Sasha Levin wrote:
> This means that missing CVE fixes are quite common with stable trees?

Until someone reports they are missing :-)

Willy

[toc] | [prev] | [next] | [standalone]

#1386991

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2016-04-21 at 16:33 +0200, Willy Tarreau wrote:
> On Thu, Apr 21, 2016 at 10:27:46AM -0400, Sasha Levin wrote:
> > 
> > This means that missing CVE fixes are quite common with stable
> > trees?
> Until someone reports they are missing :-)

Or they are unfixed upstream (there are a good few of those).

Debian has a public list of all unembargoed kernel security issues that
have CVEs (and a few that don't), with references to any upstream
commits and fixed stable versions - but only for the stable branches
that our stable releases follow.

The mapping of CVE IDs to commits may be useful to other stable
maintainers, even if the rest isn't.

svn co svn://scm.alioth.debian.org/svn/kernel-sec/

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
                                                            - Robert Coveyou

[toc] | [prev] | [next] | [standalone]

#1387131

On Tue, Apr 26, 2016 at 01:14:13AM +0200, Ben Hutchings wrote:
> On Thu, 2016-04-21 at 16:33 +0200, Willy Tarreau wrote:
> > On Thu, Apr 21, 2016 at 10:27:46AM -0400, Sasha Levin wrote:
> > > 
> > > This means that missing CVE fixes are quite common with stable
> > > trees?
> > Until someone reports they are missing :-)
> 
> Or they are unfixed upstream (there are a good few of those).
> 
> Debian has a public list of all unembargoed kernel security issues that
> have CVEs (and a few that don't), with references to any upstream
> commits and fixed stable versions - but only for the stable branches
> that our stable releases follow.
> 
> The mapping of CVE IDs to commits may be useful to other stable
> maintainers, even if the rest isn't.
> 
> svn co svn://scm.alioth.debian.org/svn/kernel-sec/

Thanks for sharing this Ben, it can indeed be helpful sometimes and it's
well organized!

Willy

[toc] | [prev] | [next] | [standalone]

#1384135

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1384261

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web