Security updates of Linux kernel (was: Re: Year 2038 time set problem)

[Greg KH]

On Mon, Feb 26, 2018 at 04:24:34PM +0100, Piotr Figiel wrote:
> Hi,
> 
> 2018-02-26 15:16 GMT+01:00 Greg KH <greg at kroah.com>:
> > On Mon, Feb 26, 2018 at 02:15:53PM +0100, Piotr Figiel wrote:
> >> 2018-02-24 16:50 GMT+01:00 Greg KH <greg at kroah.com>:
> >> > Also note that the 4.1 kernel is very old and obsolete and insecure, and
> >> > should NOT be used for any devices in the year 2038.
> >> According to kernel.org website 4.1 has projected EOL in May 2018.
> > Yes, 3 months from now.
> >> Is the information about kernel releases on kernel.org irrelevant/
> >> shouldn't be trusted? Or my understanding of longterm kernel trees is
> >> incorrect?
> > No, it is correct, but note that since 4.1.y is about to be end-of-life,
> > it is receiving very few updates.  No new device should be considering
> > to use it for their kernel version because it will not be supported very
> > soon now.
> 
> Yes, that's clear. I'm just concerned a bit that you wrote that 4.1 is
> already insecure (while it's stated on kernel.org that it's currently
> supported). I just wonder where is the boundary as to one can expect
> the kernel to still get the security updates.

It all depends.  Right now, 4.1.y is vulnerable to the Spectre issue.
As is 4.4.y.  Will those kernels ever get those fixes, who knows, do you
want to do the backport work, or just update to a newer kernel?

And depending on your architecture, 4.4.y and 4.9.y is vunerable to
Meltdown as well.  And those kernels will not get fixed for known
reasons I've documented elsewhere.

There are other issues that are fixed in newer kernels that are not
backported further back due to various issues, so you should always use
a newer kernel release to be sure.

> Is there a consensus about a reliable source of information which
> kernels get fixes for certain security issues? Or is sticking with the
> most recent /stable/ kernel the only recommended approach?

This.

> Commit messages often didn't mention any CVE or didn't indicate
> clearly a security problem so it's pretty hard to track it
> (semi-manually or automatically or without going in depth into commit
> details).

CVEs mean nothing, you can't rely on them.  They are only good for if a
bug is reported to the CVE numbering people, that's it.  And even then,
can you properly track a CVE issue that takes 100s of patches to resolve
(like Meltdown and Spectre do?)  I sure can not...

For a full description on this whole thing, please see this post where I
describe how the kernel developers treat "security" bugs, and how to
ensure you are running a secure system:
	http://www.kroah.com/log/blog/2018/02/05/linux-kernel-release-model/

Hope this helps,

greg k-h