I would like to try to clarify a few points in the article, "Handling
kernel security problems" by Jonathan Corbet.
First off, I speak only for myself, not for the other half of the Linux
-stable team, Chris Wright, who might totally disagree with me, nor for
the other kernel developers who help out with the firstname.lastname@example.org
alias, nor for my current employer Novell. Also note that all of my
-stable development is done on my own time, and is not part of my role
at my current job.
All of that out of the way, I object to a few things stated in the
It does seem that there has been a trend away from explicit
recognition of security issues in the stable releases. The
inclusion of CVE numbers was once common; in the 2.6.25 series,
only 188.8.131.52, 184.108.40.206, and 220.127.116.11 had such numbers in the
changelogs. It is, indeed, true that a straightforward reading of
the stable release changelogs will not tell users whether those
releases fix relevant security issues.
A number of times, when we do -stable releases, there are no CVE numbers
issued for the "security" related issues that are fixed in there. This
happens when the fix is first made in Linus's tree, and is either
forwarded to the email@example.com alias saying, "we need to get this
out now", or just by the fact that it is only later that people realize
that a CVE number should be allocated.
And yes, the trend is away from explicit recognition of security issues,
exactly following Linus's statement that you quote from.
It comes down to who are the users of the -stable kernel series. I
personally see these kernels for two different groups of people:
- Those who want to follow the latest kernel.org releases and not rely
on a distribution for their kernel versions.
- For distributions to base releases on, and to pick and choose
The first group should always update to the latest -stable kernel update
as they are relying on the -stable team to always provide them the
latest fixes that are known to be needed for them. Simply marking
things as "security related" can be misguided as Linus points out. The
change log entries should show all users what was fixed, and if they run
machine where this code is used, then they should upgrade. It's as
simple as that.
In fact, in the 18.104.22.168 release I tried to say exactly that:
It contains one bugfix, any user of the 2.6.25 kernel on x86-64
with untrusted local users is very STRONGLY recommended to
How much clearer can I be? Does a user of the -stable tree, who has to be
technically competent to be able to do such a thing in the first place,
need to know more to decide if they need to upgrade their machines or not?
It seems people are upset that I am no longer using the magic words
"security fix", and that is true, I am not saying that anymore.
As Linus and others have noted, marking some bugs as being
"security-related" is not helpful, especially as not everyone can even
agree - or sometimes even know at release time - whether a bug has security
implications or not.
Also note that this release does not refer to a CVE number. This is
because, as of this moment, there still is not a number assigned,
despite asking the relevant groups for such an assignment. I never want
to hold up a release by waiting for any such number, so I personally
will just not use them in the future in -stable releases unless they are
already contained in the original changelog entry in Linus's tree.
The second group, the distributions, all seem very happy with how the
-stable releases are conducted. They have the capability to pick and
choose from the fixes and apply them to their older kernel versions and
ship them to their customers as they see fit. The distros all know what
things are security related by the fact that they know and understand
the code and the threat model as they have developers assigned to
handle such security issues, and have done so for years.
In your summary, you state:
It is good to have a clear sense for what the security problems in a
piece of code are. If nothing else, it helps the project itself to
understand where it stands with regard to security and whether things
are getting better or worse. So it would be nice if the kernel
developers could be a bit more diligent and organized in how they
track security issues, much like the tracking of regressions has
improved over the last couple of years.
I think the individual developers of the kernel all know quite well what
the security problems for their code are. This is backed up by the fact
that these developers are the ones usually making the fix and telling
the -stable team that a specific patch is needed to be added.
What you seem to be asking for is a way to somehow classify bugs and
fixes in the kernel tree as "security related" or not. And that goes
back to Linus's original point. To try to do so marginalizes bugs which
are somehow not so designated as not worth fixing.
However, if someone wants to do this work for the kernel community,
and it proves to be useful over time, I'll be the first in line to say
that I was wrong.
to post comments)