[v3] Documentation: Document the Linux Kernel CVE process

  The Linux kernel project now has the ability to assign CVEs to fixed
issues, so document the process and how individual developers can get a
CVE if one is not automatically assigned for their fixes.

Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
---
v3: fix up wording in security-bugs.rst based on the changes to the cve
    assignment process from v1, thanks to a private reviewer for
    pointing that out.
v2: Grammer fixes based on review from Randy
    Updated paragraph about how CVE identifiers will be assigned
    (automatically when added to stable trees, or ask us for one
    directly before that happens if so desired)

 Documentation/process/cve.rst           | 120 ++++++++++++++++++++++++
 Documentation/process/index.rst         |   1 +
 Documentation/process/security-bugs.rst |   5 +-
 3 files changed, 123 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/process/cve.rst
  

On Wed, Feb 14, 2024 at 9:01 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> The Linux kernel project now has the ability to assign CVEs to fixed
> issues, so document the process and how individual developers can get a
> CVE if one is not automatically assigned for their fixes.
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> Signed-off-by: Lee Jones <lee@kernel.org>
> ---
> v3: fix up wording in security-bugs.rst based on the changes to the cve
>     assignment process from v1, thanks to a private reviewer for
>     pointing that out.
> v2: Grammer fixes based on review from Randy
>     Updated paragraph about how CVE identifiers will be assigned
>     (automatically when added to stable trees, or ask us for one
>     directly before that happens if so desired)
>

Hi Greg, Sasha, Lee,

Generally, I think this is a great step forward on the whole "security
vulnerability mess" and this will certainly help me and others in the
embedded space to argue to update to recent stable kernel versions.
This can then finally put the practice of shipping multiple-year-old
kernel versions to an end. Often this was just done with the argument
that there is not a recent CVE and fix assigned to some recent stable
kernel version---and integrators think updates to recent kernel stable
versions are not needed and not recommended.

I am looking forward to seeing what and how many stable commits are
going to get CVEs assigned. If Greg's policy from the Kernel Recipes
2019 presentation comes into play, every git kernel hash (GKH)---at
least in the stable tree---could get a CVE identifier (just to be on
the safe side). But I assume you are going to use some expert
knowledge, heuristics or some machine-learning AI to make some commits
in the stable tree carrying a CVE identifier and some others not.

Reviewed-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>

Below, there is just some nitpicking on some wording:

>  Documentation/process/cve.rst           | 120 ++++++++++++++++++++++++
>  Documentation/process/index.rst         |   1 +
>  Documentation/process/security-bugs.rst |   5 +-
>  3 files changed, 123 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/process/cve.rst
>
> diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst
> new file mode 100644
> index 000000000000..6465e6a79c18
> --- /dev/null
> +++ b/Documentation/process/cve.rst
> @@ -0,0 +1,120 @@
> +CVEs
> +====
> +
> +Common Vulnerabilities and Exposure (CVE®) numbers were developed as an
> +unambiguous way to identify, define, and catalog publicly disclosed
> +security vulnerabilities.  Over time, their usefulness has declined with
> +regards to the kernel project, and CVE numbers were very often assigned
> +in inappropriate ways and for inappropriate reasons.  Because of this,
> +the kernel development community has tended to avoid them.  However, the
> +combination of continuing pressure to assign CVEs and other forms of
> +security identifiers, and ongoing abuses by community members outside of
> +the kernel community has made it clear that the kernel community should
> +have control over those assignments.
> +

Though, I get what is meant with "the community members outside of the
kernel community", it still feels strange when reading.

Here are some alternatives I could come up with:

"reporters outside the kernel community"
"reporters beyond the actively contributing/engaged kernel community members"
"individuals not engaged with the kernel community"

> +The Linux kernel developer team does have the ability to assign CVEs for
> +potential Linux kernel security issues.  This assignment is independent
> +of the :doc:`normal Linux kernel security bug reporting
> +process<../process/security_bugs>`.
> +
> +A list of all assigned CVEs for the Linux kernel can be found in the
> +archives of the linux-cve mailing list, as seen on
> +https://lore.kernel.org/linux-cve-announce/.  To get notice of the
> +assigned CVEs, please subscribe to that mailing list.
> +
> +Process
> +-------
> +
> +As part of the normal stable release process, kernel changes that are
> +potentially security issues are identified by the developers responsible
> +for CVE number assignments and have CVE numbers automatically assigned
> +to them.  These assignments are published on the linux-cve-announce
> +mailing list as announcements on a frequent basis.
> +
> +Note, due to the layer at which the Linux kernel is in a system, almost
> +any bug might be exploitable to compromise the security of the kernel,

Just a nit: but I would say: a kernel bug is compromising the
"security of the system"; the kernel bug just happens to allow anyone
to run any code on their hardware... in some systems that is a
security issue, but in my previous MSDOS system that was the default
behaviour ;)

> +but the possibility of exploitation is often not evident when the bug is
> +fixed.  Because of this, the CVE assignment team is overly cautious and
> +assign CVE numbers to any bugfix that they identify.  This
> +explains the seemingly large number of CVEs that are issued by the Linux
> +kernel team.
> +
> +If the CVE assignment team misses a specific fix that any user feels
> +should have a CVE assigned to it, please email them at <cve@kernel.org>
> +and the team there will work with you on it.  Note that no potential
> +security issues should be sent to this alias, it is ONLY for assignment
> +of CVEs for fixes that are already in released kernel trees.  If you
> +feel you have found an unfixed security issue, please follow the
> +:doc:`normal Linux kernel security bug reporting
> +process<../process/security_bugs>`.
> +
> +No CVEs will be automatically assigned for unfixed security issues in
> +the Linux kernel; assignment will only automatically happen after a fix
> +is available and applied to a stable kernel tree, and it will be tracked
> +that way by the git commit id of the original fix.  If anyone wishes to
> +have a CVE assigned before an issue is resolved with a commit, please
> +contact the kernel CVE assignment team at <cve@kernel.org> to get an
> +identifier assigned from their batch of reserved identifiers.
> +
> +No CVEs will be assigned for any issue found in a version of the kernel
> +that is not currently being actively supported by the Stable/LTS kernel
> +team.  A list of the currently supported kernel branches can be found at
> +https://kernel.org/category/releases.html
> +
> +Disputes of assigned CVEs
> +-------------------------
> +
> +The authority to dispute or modify an assigned CVE for a specific kernel
> +change lies solely with the maintainers of the relevant subsystem
> +affected.  This principle ensures a high degree of accuracy and
> +accountability in vulnerability reporting.  Only those individuals with
> +deep expertise and intimate knowledge of the subsystem can effectively
> +assess the validity and scope of a reported vulnerability and determine
> +its appropriate CVE designation.  Any attempt to modify or dispute a CVE
> +outside of this designated authority could lead to confusion, inaccurate
> +reporting, and ultimately, compromised systems.
> +
> +Invalid CVEs
> +------------
> +
> +If a security issue is found in a Linux kernel that is only supported by
> +a Linux distribution due to the changes that have been made by that
> +distribution, or due to the distribution supporting a kernel version
> +that is no longer one of the kernel.org supported releases, then a CVE
> +can not be assigned by the Linux kernel CVE team, and must be asked for
> +from that Linux distribution itself.
> +
> +Any CVE that is assigned against the Linux kernel for an actively
> +supported kernel version, by any group other than the kernel assignment
> +CVE team should not be treated as a valid CVE.  Please notify the
> +kernel CVE assignment team at <cve@kernel.org> so that they can work to
> +invalidate such entries through the CNA remediation process.
> +
> +Applicability of specific CVEs
> +------------------------------
> +
> +As the Linux kernel can be used in many different ways, with many
> +different ways of accessing it by external users, or no access at all,
> +the applicability of any specific CVE is up to the user of Linux to
> +determine, it is not up to the CVE assignment team.  Please do not
> +contact us to attempt to determine the applicability of any specific
> +CVE.
> +
> +Also, as the source tree is so large, and any one system only uses a
> +small subset of the source tree, any users of Linux should be aware that
> +large numbers of assigned CVEs are not relevant for their systems.
> +
> +In short, we do not know your use case, and we do not know what portions
> +of the kernel that you use, so there is no way for us to determine if a
> +specific CVE is relevant for your system.
> +
> +As always, it is best to take all released kernel changes, as they are
> +tested together in a unified whole by many community members, and not as
> +individual cherry-picked changes.  Also note that for many bugs, the
> +solution to the overall problem is not found in a single change, but by
> +the sum of many fixes on top of each other.  Ideally CVEs will be
> +assigned to all fixes for all issues, but sometimes we do not notice
> +fixes in released kernels, so do not assume that because a specific
> +change does not have a CVE assigned to it, that it is not relevant to
> +take.
> +
> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
> index 6cb732dfcc72..de9cbb7bd7eb 100644
> --- a/Documentation/process/index.rst
> +++ b/Documentation/process/index.rst
> @@ -81,6 +81,7 @@ of special classes of bugs: regressions and security problems.
>
>     handling-regressions
>     security-bugs
> +   cve
>     embargoed-hardware-issues
>
>  Maintainer information
> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> index 692a3ba56cca..56c560a00b37 100644
> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> @@ -99,9 +99,8 @@ CVE assignment
>  The security team does not assign CVEs, nor do we require them for
>  reports or fixes, as this can needlessly complicate the process and may
>  delay the bug handling.  If a reporter wishes to have a CVE identifier
> -assigned, they should find one by themselves, for example by contacting
> -MITRE directly.  However under no circumstances will a patch inclusion
> -be delayed to wait for a CVE identifier to arrive.
> +assigned for a confirmed issue, they can contact the :doc:`kernel CVE
> +assignment team<../process/cve>` to obtain one.
>
>  Non-disclosure agreements
>  -------------------------
> --
> 2.43.1
>
>
  

On 14/02/2024 09:00, Greg Kroah-Hartman wrote:
> diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst
> new file mode 100644
> index 000000000000..6465e6a79c18
> --- /dev/null
> +++ b/Documentation/process/cve.rst
> @@ -0,0 +1,120 @@
> +CVEs
> +====

Document titles should have ==== above them as well, and then you would
need to shift all the other headings in this document (i.e. all the ---
should become ===).

Info here: 
https://docs.kernel.org/doc-guide/sphinx.html#specific-guidelines-for-the-kernel-documentation

> +The Linux kernel developer team does have the ability to assign CVEs for
> +potential Linux kernel security issues.  This assignment is independent
> +of the :doc:`normal Linux kernel security bug reporting
> +process<../process/security_bugs>`.

These documents are both under process/ so it should be enough to say:

:doc:`[...] <security-bugs>`

In fact, when building the docs with your patch applied, I see:

Documentation/process/cve.rst:15: WARNING: unknown document: 
./process/security_bugs
Documentation/process/cve.rst:42: WARNING: unknown document: 
./process/security_bugs

Note the hyphen vs. underscore (it should have a hyphen like my line above).

> +Process
> +-------
> +
> +As part of the normal stable release process, kernel changes that are
> +potentially security issues are identified by the developers responsible
> +for CVE number assignments and have CVE numbers automatically assigned
> +to them.  These assignments are published on the linux-cve-announce
> +mailing list as announcements on a frequent basis.
> +
> +Note, due to the layer at which the Linux kernel is in a system, almost
> +any bug might be exploitable to compromise the security of the kernel,
> +but the possibility of exploitation is often not evident when the bug is
> +fixed.  Because of this, the CVE assignment team is overly cautious and

What is the composition of the CVE assignment team, or is that secret?
Should this be a MAINTAINERS entry? (s@k.org is one.)

> +If the CVE assignment team misses a specific fix that any user feels
> +should have a CVE assigned to it, please email them at <cve@kernel.org>
> +and the team there will work with you on it.  Note that no potential
> +security issues should be sent to this alias, it is ONLY for assignment
> +of CVEs for fixes that are already in released kernel trees.  If you
> +feel you have found an unfixed security issue, please follow the
> +:doc:`normal Linux kernel security bug reporting
> +process<../process/security_bugs>`.

Same

> +Disputes of assigned CVEs
> +-------------------------
> +
> +The authority to dispute or modify an assigned CVE for a specific kernel
> +change lies solely with the maintainers of the relevant subsystem
> +affected.  This principle ensures a high degree of accuracy and
> +accountability in vulnerability reporting.  Only those individuals with
> +deep expertise and intimate knowledge of the subsystem can effectively
> +assess the validity and scope of a reported vulnerability and determine
> +its appropriate CVE designation.  Any attempt to modify or dispute a CVE
> +outside of this designated authority could lead to confusion, inaccurate
> +reporting, and ultimately, compromised systems.

Just to clarify, I think "dispute" here is used in the
Mitre/CVE-technical meaning of the word, correct? I assume people will
still have the right to say "hey, this doesn't look like a real issue
[because of X/Y/Z]" on a mailing list.

> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> @@ -99,9 +99,8 @@ CVE assignment
>   The security team does not assign CVEs, nor do we require them for
>   reports or fixes, as this can needlessly complicate the process and may
>   delay the bug handling.  If a reporter wishes to have a CVE identifier
> -assigned, they should find one by themselves, for example by contacting
> -MITRE directly.  However under no circumstances will a patch inclusion
> -be delayed to wait for a CVE identifier to arrive.
> +assigned for a confirmed issue, they can contact the :doc:`kernel CVE
> +assignment team<../process/cve>` to obtain one.

Same here, this could be just <cve>.


Vegard
  

On 14/02/2024 09:00, Greg Kroah-Hartman wrote:
> The Linux kernel project now has the ability to assign CVEs to fixed
> issues, so document the process and how individual developers can get a
> CVE if one is not automatically assigned for their fixes.
> 
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> Signed-off-by: Lee Jones <lee@kernel.org>
> ---
> v3: fix up wording in security-bugs.rst based on the changes to the cve
>     assignment process from v1, thanks to a private reviewer for
>     pointing that out.
> v2: Grammer fixes based on review from Randy
>     Updated paragraph about how CVE identifiers will be assigned
>     (automatically when added to stable trees, or ask us for one
>     directly before that happens if so desired)
> 
>  Documentation/process/cve.rst           | 120 ++++++++++++++++++++++++
>  Documentation/process/index.rst         |   1 +
>  Documentation/process/security-bugs.rst |   5 +-

Great direction! Finally all these bugs we are fixing every release
(thus in stable trees) will get proper attention via assigned CVEs.

Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>

Best regards,
Krzysztof
  

On Wed, Feb 14, 2024 at 09:00:30AM +0100, Greg Kroah-Hartman wrote:
> +A list of all assigned CVEs for the Linux kernel can be found in the
> +archives of the linux-cve mailing list, as seen on
> +https://lore.kernel.org/linux-cve-announce/.  To get notice of the
> +assigned CVEs, please subscribe to that mailing list.

Since the archives page doesn't carry any instructions on how to subscribe,
I think you should link to https://subspace.kernel.org/subscribing.html here,
e.g.:

.. please `subscribe <https://subspace.kernel.org/subscribing.html>`_ to that
mailing list.

> +No CVEs will be assigned for any issue found in a version of the kernel
> +that is not currently being actively supported by the Stable/LTS kernel
> +team.  A list of the currently supported kernel branches can be found at
> +https://kernel.org/category/releases.html

Can just be https://kernel.org/releases.html

Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>

-K
  

On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote:

> +No CVEs will be automatically assigned for unfixed security issues in
> +the Linux kernel; assignment will only automatically happen after a fix
> +is available and applied to a stable kernel tree, and it will be tracked
> +that way by the git commit id of the original fix. 

I think this needs way more clarification .. how exactly is this going to 
work?

Do I read this correctly that *everything* that lands in -stable will 
automatically get CVE assigned? If so, that's just plain crazy. Just took 
a random peek on the topmost -stable changelog ...

	ASoC: codecs: wsa883x: fix PA volume control
	ASoC: codecs: lpass-wsa-macro: fix compander volume hack
	ASoC: codecs: wcd938x: fix headphones volume controls
	ASoC: qcom: sc8280xp: limit speaker volumes
	drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()'

Only the last one can *potentially* be considered a CVE candidate, but 
someone would actually have to take a *deep* look. Most likely it'll be a 
functional issue, but not a security issue by any measures.

So I hope it's not the case, and someone will actually be doing some 
triage. If that's the case -- is this process described anywhere?

Also, how are the CVSS-like scores going to be assigned? There are no 
details whatsoever about that in the document.

In any case, by making this change we are going to make security theathre 
industry super-happy (they will have a lot of expensive nothing going on), 
and all the distros not basing on -stable very unhappy (we're already 
drowning because everybody and his grandma wants to become famous by 
publishing a CVE for something completely irrelevant). If this is the 
intention, it should be spelled out loud and clear.

Thanks,
  

On Wed, Feb 14, 2024 at 02:43:48PM +0100, Jiri Kosina wrote:
> On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote:

> > +No CVEs will be automatically assigned for unfixed security issues in
> > +the Linux kernel; assignment will only automatically happen after a fix
> > +is available and applied to a stable kernel tree, and it will be tracked
> > +that way by the git commit id of the original fix. 

> I think this needs way more clarification .. how exactly is this going to 
> work?

> Do I read this correctly that *everything* that lands in -stable will 
> automatically get CVE assigned? If so, that's just plain crazy. Just took 
> a random peek on the topmost -stable changelog ...

> 	ASoC: codecs: wsa883x: fix PA volume control
> 	ASoC: codecs: lpass-wsa-macro: fix compander volume hack
> 	ASoC: codecs: wcd938x: fix headphones volume controls
> 	ASoC: qcom: sc8280xp: limit speaker volumes
> 	drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()'

> Only the last one can *potentially* be considered a CVE candidate, but 
> someone would actually have to take a *deep* look. Most likely it'll be a 
> functional issue, but not a security issue by any measures.

Not addressing your point in general but the speaker volume limiting is
security relevant, that change prevents physical damage to the system.
There's an argument for many headphone volume related fixes too since
excessively large volumes can cause substantial distress and potential
injury to users (I can't remember if that fix would be relevant to that
issue).
  

On Wed, Feb 14, 2024 at 02:43:48PM +0100, Jiri Kosina wrote:
> On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote:
> 
> > +No CVEs will be automatically assigned for unfixed security issues in
> > +the Linux kernel; assignment will only automatically happen after a fix
> > +is available and applied to a stable kernel tree, and it will be tracked
> > +that way by the git commit id of the original fix. 
> 
> I think this needs way more clarification .. how exactly is this going to 
> work?
> 
> Do I read this correctly that *everything* that lands in -stable will 
> automatically get CVE assigned? If so, that's just plain crazy. Just took 
> a random peek on the topmost -stable changelog ...
> 
> 	ASoC: codecs: wsa883x: fix PA volume control
> 	ASoC: codecs: lpass-wsa-macro: fix compander volume hack
> 	ASoC: codecs: wcd938x: fix headphones volume controls
> 	ASoC: qcom: sc8280xp: limit speaker volumes
> 	drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()'
> 
> Only the last one can *potentially* be considered a CVE candidate, but 
> someone would actually have to take a *deep* look. Most likely it'll be a 
> functional issue, but not a security issue by any measures.
> 
> So I hope it's not the case, and someone will actually be doing some 
> triage. If that's the case -- is this process described anywhere?

It's described as "we know it when we see it" :)

Seriously, this is something that Sasha has already been doing
successfully for 3+ years now with the GSD project, so look at the
commits that have been assigned there for an example of what will be
picked.  Also we will probably go back in time for a few years and use
that data to populate the CVE database for older releases as long as
they are still in currently supported releases as this is something that
the CVE group has asked us to do already.

As for your list above, I doubt any of those would be a CVE, give us
some credit here.  Let's see how it goes and if people complain we are
picking things that we shouldn't be picking, OR if we aren't picking
enough, they will then be asked to join the team doing the work :)

The people that make up the current team, Lee, Sasha, and I, have a LONG
history of fixing and triaging and managing security bugs for the
kernel, in the community and in corporate environments.  We know how to
do this as we have been doing it for decades already.  If you or anyone
else wishes to help us out with this classification, we can gladly use
the help.

> Also, how are the CVSS-like scores going to be assigned? There are no 
> details whatsoever about that in the document.

We will not be doing any CVSS scoring as that is outside the scope of a
CVE entry and not required at all, and the CVE board agrees with this
decision.  As you well know, doing something like this for the kernel
where we have no idea what your use case is, is almost impossible on the
best days.

There are external groups that suck in the CVE entries and attempt to
assign CVSS-like scores to issues.  It will be "interesting" to see how
they classify things, but if the history of how well they have done this
in the past is any indication, their tools need a lot of work and
hopefully people stop relying on them and do the evaluation of their own
use cases instead.

> In any case, by making this change we are going to make security theathre 
> industry super-happy (they will have a lot of expensive nothing going on), 
> and all the distros not basing on -stable very unhappy (we're already 
> drowning because everybody and his grandma wants to become famous by 
> publishing a CVE for something completely irrelevant). If this is the 
> intention, it should be spelled out loud and clear.

As we are not allowed to credit anyone in the publication of a CVE, I
doubt the "I want a CVE!" group will get any louder than they currently
are.  And if it generates these people to actually submit bug fixes with
their reports, all the better for us!

I can't speak to the "security theatre industry" but right now, we have
a real problem of external groups assigning random CVEs to the kernel
with absolutely no input from us and no accountability, which is causing
a lot of us real problems.  This will take away the ability for those
groups to continue to abuse our project just because of their broken
engineering rules, and properly integrate them into our development
process if they so desire to join in.

thanks,

greg k-h
  

On Wed, Feb 14, 2024 at 01:55:43PM +0000, Mark Brown wrote:
> On Wed, Feb 14, 2024 at 02:43:48PM +0100, Jiri Kosina wrote:
> > On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote:
> 
> > > +No CVEs will be automatically assigned for unfixed security issues in
> > > +the Linux kernel; assignment will only automatically happen after a fix
> > > +is available and applied to a stable kernel tree, and it will be tracked
> > > +that way by the git commit id of the original fix. 
> 
> > I think this needs way more clarification .. how exactly is this going to 
> > work?
> 
> > Do I read this correctly that *everything* that lands in -stable will 
> > automatically get CVE assigned? If so, that's just plain crazy. Just took 
> > a random peek on the topmost -stable changelog ...
> 
> > 	ASoC: codecs: wsa883x: fix PA volume control
> > 	ASoC: codecs: lpass-wsa-macro: fix compander volume hack
> > 	ASoC: codecs: wcd938x: fix headphones volume controls
> > 	ASoC: qcom: sc8280xp: limit speaker volumes
> > 	drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()'
> 
> > Only the last one can *potentially* be considered a CVE candidate, but 
> > someone would actually have to take a *deep* look. Most likely it'll be a 
> > functional issue, but not a security issue by any measures.
> 
> Not addressing your point in general but the speaker volume limiting is
> security relevant, that change prevents physical damage to the system.
> There's an argument for many headphone volume related fixes too since
> excessively large volumes can cause substantial distress and potential
> injury to users (I can't remember if that fix would be relevant to that
> issue).

And this points to the fact that we now have a way, if a
maintainer/developer says "hey, that commit could be a potential issue,
I want to call that out to others!" they now have a path to do so.  Just
email cve@kernel.org "can you assign a cve to git id XXXX because of
YYY" and we will do so.

thanks!

greg k-h
  

On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote:

> The people that make up the current team, Lee, Sasha, and I, have a LONG
> history of fixing and triaging and managing security bugs for the
> kernel, in the community and in corporate environments.  We know how to
> do this as we have been doing it for decades already.  

Thanks for clarifying. Maybe the wording could use some more verbosity 
then; one of my potential readings of it was "everything that gets picked 
for -stable will get a CVE assigned".

> If you or anyone else wishes to help us out with this classification, we 
> can gladly use the help.

Thanks, but no, thanks, I want to stay away from the CVE tragedy as far as 
possible :)
  

On Wed, 14 Feb 2024, Mark Brown wrote:

> Not addressing your point in general but the speaker volume limiting is
> security relevant, that change prevents physical damage to the system.
> There's an argument for many headphone volume related fixes too since
> excessively large volumes can cause substantial distress and potential
> injury to users (I can't remember if that fix would be relevant to that
> issue).

Thanks, I guess you are actually supporting my point, and that is -- there 
is no consensus whatsoever of what assigning a CVE actually means, at all.

To me -- physical damage to the system, fair enough, that might really 
easily be security relevant.

Something being too loud, causing distress ... that's really a grey zone 
(to put it mildly) for me. How about e.g. a bug in GPU driver, leading to 
a flickering screen? Many people are very sensitive to that (both 
physically and mentally) for various reasons.

Bug worth fixing? Absolutely, as soon as possible. Security-relevant? Not 
in my book.

To me, kernel is in no way special, in this respect, actually. With each 
and every coding error in software of your choice, given anough fantasy, 
you'll come up with a scenario where this will cause some real issues to 
some living human.

That's not what CVE is about at all, at least in my understaing.
  

On Wed, Feb 14, 2024 at 03:38:52PM +0100, Jiri Kosina wrote:
> On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote:
> 
> > The people that make up the current team, Lee, Sasha, and I, have a LONG
> > history of fixing and triaging and managing security bugs for the
> > kernel, in the community and in corporate environments.  We know how to
> > do this as we have been doing it for decades already.  
> 
> Thanks for clarifying. Maybe the wording could use some more verbosity 
> then; one of my potential readings of it was "everything that gets picked 
> for -stable will get a CVE assigned".

CVE has a very specific definition already, as per cve.org:

	 CVE Record is the descriptive data about a vulnerability
	 associated with a CVE ID, provided by a CVE Numbering Authority
	 (CNA). This data is provided in multiple human and
	 machine-readable formats.

And they define "vulnerability" as:

	An instance of one or more weaknesses in a Product that can be
	exploited, causing a negative impact to confidentiality,
	integrity, or availability; a set of conditions or behaviors
	that allows the violation of an explicit or implicit security
	policy.

and as a CNA we must follow that definition.  No need to restate the CVE
rules in our own document, I am sure that if we don't follow them, lots
of people will be quick to point it out and we will revoke those ids
that we mess up on.

thanks,

greg k-h
  

On Wed, Feb 14, 2024 at 03:46:12PM +0100, Jiri Kosina wrote:
> On Wed, 14 Feb 2024, Mark Brown wrote:

> > There's an argument for many headphone volume related fixes too since
> > excessively large volumes can cause substantial distress and potential
> > injury to users (I can't remember if that fix would be relevant to that
> > issue).

> Something being too loud, causing distress ... that's really a grey zone 
> (to put it mildly) for me. How about e.g. a bug in GPU driver, leading to 
> a flickering screen? Many people are very sensitive to that (both 
> physically and mentally) for various reasons.

> Bug worth fixing? Absolutely, as soon as possible. Security-relevant? Not 
> in my book.

To be clear, most headphone drivers can easily generate output levels
which will cause temporary or permanent hearing loss after very brief
exposure.  The distress is the urgent and instinctive need to remove the
headphones as fast as possible that tends to result, much as it would
for any other ongoing source of injury.
  

On 14.02.24 09:00, Greg Kroah-Hartman wrote:
> The Linux kernel project now has the ability to assign CVEs to fixed
> issues, so document the process and how individual developers can get a
> CVE if one is not automatically assigned for their fixes.
> [...]

This following is just nitpicking, hence feel free to ignore.

> +As always, it is best to take all released kernel changes, as they are
> +tested together in a unified whole by many community members, and not as
> +individual cherry-picked changes.  Also note that for many bugs, the
> +solution to the overall problem is not found in a single change, but by
> +the sum of many fixes on top of each other.  Ideally CVEs will be
> +assigned to all fixes for all issues, but sometimes we do not notice
> +fixes in released kernels, so do not assume that because a specific
> +change does not have a CVE assigned to it, that it is not relevant to
> +take.

There are a four "not" in the last pretty long sentence which makes it
kinda hard to parse. Avoiding that could look like this:

Ideally CVEs will be assigned to all fixes for all issues -- but
sometimes we will fail to notice fixes, therefore assume that some
changes without an assigned CVE might still be relevant to take.

Or like this:

Ideally CVEs will be assigned to all fixes for all issues, but sometimes
we will overlook fixes -- therefore assume that some changes that lack
an assigned CVE might still be relevant to take.

Not sure if that really makes it better, I guess you as a native speaker
are a better judge here.

Ciao, Thorsten (who also wondered what "to all fixes for all issues"
exactly means, but whatever)
  

On Thu, Feb 15, 2024 at 09:17:59AM +0100, Thorsten Leemhuis wrote:
> On 14.02.24 09:00, Greg Kroah-Hartman wrote:
> > The Linux kernel project now has the ability to assign CVEs to fixed
> > issues, so document the process and how individual developers can get a
> > CVE if one is not automatically assigned for their fixes.
> > [...]
> 
> This following is just nitpicking, hence feel free to ignore.
> 
> > +As always, it is best to take all released kernel changes, as they are
> > +tested together in a unified whole by many community members, and not as
> > +individual cherry-picked changes.  Also note that for many bugs, the
> > +solution to the overall problem is not found in a single change, but by
> > +the sum of many fixes on top of each other.  Ideally CVEs will be
> > +assigned to all fixes for all issues, but sometimes we do not notice
> > +fixes in released kernels, so do not assume that because a specific
> > +change does not have a CVE assigned to it, that it is not relevant to
> > +take.
> 
> There are a four "not" in the last pretty long sentence which makes it
> kinda hard to parse. Avoiding that could look like this:
> 
> Ideally CVEs will be assigned to all fixes for all issues -- but
> sometimes we will fail to notice fixes, therefore assume that some
> changes without an assigned CVE might still be relevant to take.
> 
> Or like this:
> 
> Ideally CVEs will be assigned to all fixes for all issues, but sometimes
> we will overlook fixes -- therefore assume that some changes that lack
> an assigned CVE might still be relevant to take.
> 
> Not sure if that really makes it better, I guess you as a native speaker
> are a better judge here.

I like the wording change here, thanks, I'll take it for the next
revision.  It is ackward as I wrote it and your update makes it simpler
and more obvious.

> Ciao, Thorsten (who also wondered what "to all fixes for all issues"
> exactly means, but whatever)

Meaning "we will miss things" so don't assume that because we don't call
it out here, it's not important to take.  Yeah, again, ackward wording,
language is "fun"...

thanks for the review!

greg k-h
  

On Wed, Feb 14, 2024 at 09:37:31AM +0100, Vegard Nossum wrote:
> 
> On 14/02/2024 09:00, Greg Kroah-Hartman wrote:
> > diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst
> > new file mode 100644
> > index 000000000000..6465e6a79c18
> > --- /dev/null
> > +++ b/Documentation/process/cve.rst
> > @@ -0,0 +1,120 @@
> > +CVEs
> > +====
> 
> Document titles should have ==== above them as well, and then you would
> need to shift all the other headings in this document (i.e. all the ---
> should become ===).
> 
> Info here: https://docs.kernel.org/doc-guide/sphinx.html#specific-guidelines-for-the-kernel-documentation

Really?  I copied this directly from
Documentation/process/security-bugs.rst which is in the format that I
used here.  Which one is incorrect, I'm confused.

> > +The Linux kernel developer team does have the ability to assign CVEs for
> > +potential Linux kernel security issues.  This assignment is independent
> > +of the :doc:`normal Linux kernel security bug reporting
> > +process<../process/security_bugs>`.
> 
> These documents are both under process/ so it should be enough to say:
> 
> :doc:`[...] <security-bugs>`
> 
> In fact, when building the docs with your patch applied, I see:
> 
> Documentation/process/cve.rst:15: WARNING: unknown document:
> ./process/security_bugs
> Documentation/process/cve.rst:42: WARNING: unknown document:
> ./process/security_bugs


Odd, I would have thought that going back a directory and then into it
would work, as that's how filesystems normally are handled :)

In fact, again, security-bugs.rst has this very format, which is why I
used it, is it throwing that same warning?

> Note the hyphen vs. underscore (it should have a hyphen like my line above).

Ah, ick, nevermind, my fault, I thought I built this with it added, I'll
go fix this up and use the hyphen.

> 
> > +Process
> > +-------
> > +
> > +As part of the normal stable release process, kernel changes that are
> > +potentially security issues are identified by the developers responsible
> > +for CVE number assignments and have CVE numbers automatically assigned
> > +to them.  These assignments are published on the linux-cve-announce
> > +mailing list as announcements on a frequent basis.
> > +
> > +Note, due to the layer at which the Linux kernel is in a system, almost
> > +any bug might be exploitable to compromise the security of the kernel,
> > +but the possibility of exploitation is often not evident when the bug is
> > +fixed.  Because of this, the CVE assignment team is overly cautious and
> 
> What is the composition of the CVE assignment team, or is that secret?
> Should this be a MAINTAINERS entry? (s@k.org is one.)

Yeah, it should be a MAINTAINERS entry, I'll add that as part of the
next version of this patch.

As for the composition, it's not a "secret", but I'd prefer not to list
it individually here.  As per the signed-off-by on this patch it's Lee,
Sasha, and I for now, but I anticipate it will change over time, much
like s@k.o has.

> > +If the CVE assignment team misses a specific fix that any user feels
> > +should have a CVE assigned to it, please email them at <cve@kernel.org>
> > +and the team there will work with you on it.  Note that no potential
> > +security issues should be sent to this alias, it is ONLY for assignment
> > +of CVEs for fixes that are already in released kernel trees.  If you
> > +feel you have found an unfixed security issue, please follow the
> > +:doc:`normal Linux kernel security bug reporting
> > +process<../process/security_bugs>`.
> 
> Same

Thanks, will fix.

> > +Disputes of assigned CVEs
> > +-------------------------
> > +
> > +The authority to dispute or modify an assigned CVE for a specific kernel
> > +change lies solely with the maintainers of the relevant subsystem
> > +affected.  This principle ensures a high degree of accuracy and
> > +accountability in vulnerability reporting.  Only those individuals with
> > +deep expertise and intimate knowledge of the subsystem can effectively
> > +assess the validity and scope of a reported vulnerability and determine
> > +its appropriate CVE designation.  Any attempt to modify or dispute a CVE
> > +outside of this designated authority could lead to confusion, inaccurate
> > +reporting, and ultimately, compromised systems.
> 
> Just to clarify, I think "dispute" here is used in the
> Mitre/CVE-technical meaning of the word, correct? I assume people will
> still have the right to say "hey, this doesn't look like a real issue
> [because of X/Y/Z]" on a mailing list.

Yes, mailing list discussion is always good and encouraged and is what
is covered here as well.  There is the MITRE use of "dispute" as well,
and that too is allowed if needed, so this covers both paths.

> 
> > --- a/Documentation/process/security-bugs.rst
> > +++ b/Documentation/process/security-bugs.rst
> > @@ -99,9 +99,8 @@ CVE assignment
> >   The security team does not assign CVEs, nor do we require them for
> >   reports or fixes, as this can needlessly complicate the process and may
> >   delay the bug handling.  If a reporter wishes to have a CVE identifier
> > -assigned, they should find one by themselves, for example by contacting
> > -MITRE directly.  However under no circumstances will a patch inclusion
> > -be delayed to wait for a CVE identifier to arrive.
> > +assigned for a confirmed issue, they can contact the :doc:`kernel CVE
> > +assignment team<../process/cve>` to obtain one.
> 
> Same here, this could be just <cve>.

I'll keep it to match the other references in this file :)

many thanks for the review!

greg k-h
  

On Wed, Feb 14, 2024 at 08:41:26AM -0500, Konstantin Ryabitsev wrote:
> On Wed, Feb 14, 2024 at 09:00:30AM +0100, Greg Kroah-Hartman wrote:
> > +A list of all assigned CVEs for the Linux kernel can be found in the
> > +archives of the linux-cve mailing list, as seen on
> > +https://lore.kernel.org/linux-cve-announce/.  To get notice of the
> > +assigned CVEs, please subscribe to that mailing list.
> 
> Since the archives page doesn't carry any instructions on how to subscribe,
> I think you should link to https://subspace.kernel.org/subscribing.html here,
> e.g.:
> 
> .. please `subscribe <https://subspace.kernel.org/subscribing.html>`_ to that
> mailing list.
> 
> > +No CVEs will be assigned for any issue found in a version of the kernel
> > +that is not currently being actively supported by the Stable/LTS kernel
> > +team.  A list of the currently supported kernel branches can be found at
> > +https://kernel.org/category/releases.html
> 
> Can just be https://kernel.org/releases.html

Many thanks for the changes, now made!

greg k-h
  

On Wed, Feb 14, 2024 at 02:10:07PM +0100, Krzysztof Kozlowski wrote:
> On 14/02/2024 09:00, Greg Kroah-Hartman wrote:
> > The Linux kernel project now has the ability to assign CVEs to fixed
> > issues, so document the process and how individual developers can get a
> > CVE if one is not automatically assigned for their fixes.
> > 
> > Reviewed-by: Kees Cook <keescook@chromium.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > Signed-off-by: Lee Jones <lee@kernel.org>
> > ---
> > v3: fix up wording in security-bugs.rst based on the changes to the cve
> >     assignment process from v1, thanks to a private reviewer for
> >     pointing that out.
> > v2: Grammer fixes based on review from Randy
> >     Updated paragraph about how CVE identifiers will be assigned
> >     (automatically when added to stable trees, or ask us for one
> >     directly before that happens if so desired)
> > 
> >  Documentation/process/cve.rst           | 120 ++++++++++++++++++++++++
> >  Documentation/process/index.rst         |   1 +
> >  Documentation/process/security-bugs.rst |   5 +-
> 
> Great direction! Finally all these bugs we are fixing every release
> (thus in stable trees) will get proper attention via assigned CVEs.
> 
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>

Thanks for the review!

greg k-h
  

On Wed, Feb 14, 2024 at 09:34:38AM +0100, Lukas Bulwahn wrote:
> On Wed, Feb 14, 2024 at 9:01 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > The Linux kernel project now has the ability to assign CVEs to fixed
> > issues, so document the process and how individual developers can get a
> > CVE if one is not automatically assigned for their fixes.
> >
> > Reviewed-by: Kees Cook <keescook@chromium.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > Signed-off-by: Lee Jones <lee@kernel.org>
> > ---
> > v3: fix up wording in security-bugs.rst based on the changes to the cve
> >     assignment process from v1, thanks to a private reviewer for
> >     pointing that out.
> > v2: Grammer fixes based on review from Randy
> >     Updated paragraph about how CVE identifiers will be assigned
> >     (automatically when added to stable trees, or ask us for one
> >     directly before that happens if so desired)
> >
> 
> Hi Greg, Sasha, Lee,
> 
> Generally, I think this is a great step forward on the whole "security
> vulnerability mess" and this will certainly help me and others in the
> embedded space to argue to update to recent stable kernel versions.
> This can then finally put the practice of shipping multiple-year-old
> kernel versions to an end. Often this was just done with the argument
> that there is not a recent CVE and fix assigned to some recent stable
> kernel version---and integrators think updates to recent kernel stable
> versions are not needed and not recommended.
> 
> I am looking forward to seeing what and how many stable commits are
> going to get CVEs assigned. If Greg's policy from the Kernel Recipes
> 2019 presentation comes into play, every git kernel hash (GKH)---at
> least in the stable tree---could get a CVE identifier (just to be on
> the safe side). But I assume you are going to use some expert
> knowledge, heuristics or some machine-learning AI to make some commits
> in the stable tree carrying a CVE identifier and some others not.

Yes, that "expert knowledge" will be "review all patches by hand" just
like we do today for all that are included in the stable trees.

> Reviewed-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>

Thanks for the review.

> > +Common Vulnerabilities and Exposure (CVE®) numbers were developed as an
> > +unambiguous way to identify, define, and catalog publicly disclosed
> > +security vulnerabilities.  Over time, their usefulness has declined with
> > +regards to the kernel project, and CVE numbers were very often assigned
> > +in inappropriate ways and for inappropriate reasons.  Because of this,
> > +the kernel development community has tended to avoid them.  However, the
> > +combination of continuing pressure to assign CVEs and other forms of
> > +security identifiers, and ongoing abuses by community members outside of
> > +the kernel community has made it clear that the kernel community should
> > +have control over those assignments.
> > +
> 
> Though, I get what is meant with "the community members outside of the
> kernel community", it still feels strange when reading.
> 
> Here are some alternatives I could come up with:
> 
> "reporters outside the kernel community"
> "reporters beyond the actively contributing/engaged kernel community members"
> "individuals not engaged with the kernel community"

"community members" is a strange wording, you are right, I've replaced
it with "individuals and companies" as it has been both abusing the
system (and "individuals at companies", but that's just nit-picking...)

> > +The Linux kernel developer team does have the ability to assign CVEs for
> > +potential Linux kernel security issues.  This assignment is independent
> > +of the :doc:`normal Linux kernel security bug reporting
> > +process<../process/security_bugs>`.
> > +
> > +A list of all assigned CVEs for the Linux kernel can be found in the
> > +archives of the linux-cve mailing list, as seen on
> > +https://lore.kernel.org/linux-cve-announce/.  To get notice of the
> > +assigned CVEs, please subscribe to that mailing list.
> > +
> > +Process
> > +-------
> > +
> > +As part of the normal stable release process, kernel changes that are
> > +potentially security issues are identified by the developers responsible
> > +for CVE number assignments and have CVE numbers automatically assigned
> > +to them.  These assignments are published on the linux-cve-announce
> > +mailing list as announcements on a frequent basis.
> > +
> > +Note, due to the layer at which the Linux kernel is in a system, almost
> > +any bug might be exploitable to compromise the security of the kernel,
> 
> Just a nit: but I would say: a kernel bug is compromising the
> "security of the system"; the kernel bug just happens to allow anyone
> to run any code on their hardware... in some systems that is a
> security issue, but in my previous MSDOS system that was the default
> behaviour ;)

Good change, made, thanks!

greg k-h
  

On 15/02/2024 12:50, Greg Kroah-Hartman wrote:
> On Wed, Feb 14, 2024 at 09:37:31AM +0100, Vegard Nossum wrote:
>>
>> On 14/02/2024 09:00, Greg Kroah-Hartman wrote:
>>> diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst
>>> new file mode 100644
>>> index 000000000000..6465e6a79c18
>>> --- /dev/null
>>> +++ b/Documentation/process/cve.rst
>>> @@ -0,0 +1,120 @@
>>> +CVEs
>>> +====
>>
>> Document titles should have ==== above them as well, and then you would
>> need to shift all the other headings in this document (i.e. all the ---
>> should become ===).
>>
>> Info here: https://docs.kernel.org/doc-guide/sphinx.html#specific-guidelines-for-the-kernel-documentation
> 
> Really?  I copied this directly from
> Documentation/process/security-bugs.rst which is in the format that I
> used here.  Which one is incorrect, I'm confused.

Documentation/ currently has a mix of both formats and they both work,
but the guidelines linked above is the gold standard and what we should
aim for in new documents.

The "correct" format would thus be:

====
CVEs
====

..

Process
=======

..

At least this is my understanding; I'm happy to be corrected (and in
this case, we should also update the documentation).

Thanks for your other clarifications.


Vegard
  

On Wed 14-02-24 09:00:30, Greg KH wrote:
[...]
> +Process
> +-------
> +
> +As part of the normal stable release process, kernel changes that are
> +potentially security issues are identified by the developers responsible
> +for CVE number assignments and have CVE numbers automatically assigned
> +to them.  These assignments are published on the linux-cve-announce
> +mailing list as announcements on a frequent basis.
> +
> +Note, due to the layer at which the Linux kernel is in a system, almost
> +any bug might be exploitable to compromise the security of the kernel,
> +but the possibility of exploitation is often not evident when the bug is
> +fixed.  Because of this, the CVE assignment team is overly cautious and
> +assign CVE numbers to any bugfix that they identify.  This
> +explains the seemingly large number of CVEs that are issued by the Linux
> +kernel team.

Does the process focus only on assigning CVE numbers to a given upstream
commit(s) withou any specifics of the actual security threat covered by
the said CVE?
  

On Thu, Feb 15, 2024 at 06:54:17PM +0100, Michal Hocko wrote:
> On Wed 14-02-24 09:00:30, Greg KH wrote:
> [...]
> > +Process
> > +-------
> > +
> > +As part of the normal stable release process, kernel changes that are
> > +potentially security issues are identified by the developers responsible
> > +for CVE number assignments and have CVE numbers automatically assigned
> > +to them.  These assignments are published on the linux-cve-announce
> > +mailing list as announcements on a frequent basis.
> > +
> > +Note, due to the layer at which the Linux kernel is in a system, almost
> > +any bug might be exploitable to compromise the security of the kernel,
> > +but the possibility of exploitation is often not evident when the bug is
> > +fixed.  Because of this, the CVE assignment team is overly cautious and
> > +assign CVE numbers to any bugfix that they identify.  This
> > +explains the seemingly large number of CVEs that are issued by the Linux
> > +kernel team.
> 
> Does the process focus only on assigning CVE numbers to a given upstream
> commit(s) withou any specifics of the actual security threat covered by
> the said CVE?

Outside of the git commit text, no, we are not going to be adding
anything additional to the report, UNLESS someone wants to add
additional text to it, and then we will be glad to update a CVE entry
with the additional information.

Here's an example of what the CVE announcement is going to look like for
a "test" that we have been doing for our scripts
	https://lore.kernel.org/linux-cve-announce/2024021353-drainage-unstuffed-a7c0@gregkh/T/#u

Note, I am NOT saying this is a valid CVE-like commit, I only chose it
because it is a type of entry that our tools need to handle properly
(one where the fix was for a commit that was only in a stable tree, and
mainline never saw the problem.)  There are many different "styles" of
fixes that we need to handle when it comes to version information.

It will also be in JSON format on the cve.org site if you wish to parse
it automatically with tools.  We are still working out the proper format
of the JSON entries of the version information and should hopefully have
an agreement of how to do this early next week, as the logic there isn't
exactly "simple".

If the announcement format needs additional work, please let us know.

thanks,

greg k-h
  

On Thu 15-02-24 19:20:09, Greg KH wrote:
> On Thu, Feb 15, 2024 at 06:54:17PM +0100, Michal Hocko wrote:
> > On Wed 14-02-24 09:00:30, Greg KH wrote:
> > [...]
> > > +Process
> > > +-------
> > > +
> > > +As part of the normal stable release process, kernel changes that are
> > > +potentially security issues are identified by the developers responsible
> > > +for CVE number assignments and have CVE numbers automatically assigned
> > > +to them.  These assignments are published on the linux-cve-announce
> > > +mailing list as announcements on a frequent basis.
> > > +
> > > +Note, due to the layer at which the Linux kernel is in a system, almost
> > > +any bug might be exploitable to compromise the security of the kernel,
> > > +but the possibility of exploitation is often not evident when the bug is
> > > +fixed.  Because of this, the CVE assignment team is overly cautious and
> > > +assign CVE numbers to any bugfix that they identify.  This
> > > +explains the seemingly large number of CVEs that are issued by the Linux
> > > +kernel team.
> > 
> > Does the process focus only on assigning CVE numbers to a given upstream
> > commit(s) withou any specifics of the actual security threat covered by
> > the said CVE?
> 
> Outside of the git commit text, no, we are not going to be adding
> anything additional to the report, UNLESS someone wants to add
> additional text to it, and then we will be glad to update a CVE entry
> with the additional information.

OK, so what is the point of having CVE assigned to such a commit without
any addional information which is already referenced by the kernel sha?
What is the actual added value of that CVE?

> Here's an example of what the CVE announcement is going to look like for
> a "test" that we have been doing for our scripts
> 	https://lore.kernel.org/linux-cve-announce/2024021353-drainage-unstuffed-a7c0@gregkh/T/#u

Thanks this gave me some idea. One worrying part is
: Please note that only supported kernel versions have fixes applied to
: them.  For a full list of currently supported kernel versions, please
: see https://www.kernel.org/

From the above it is not really clear "supported by _whom_". Because I
am pretty sure there are _fully_ supported kernels outside of that list
which are actively maintained.
  

On Thu, Feb 15, 2024 at 07:20:09PM +0100, Greg Kroah-Hartman wrote:
> Here's an example of what the CVE announcement is going to look like for
> a "test" that we have been doing for our scripts
> 	https://lore.kernel.org/linux-cve-announce/2024021353-drainage-unstuffed-a7c0@gregkh/T/#u
> ...
> the latest release is impossible, the individual change to resolve this
> issue can be found at:
> 	https://git.kernel.org/stable/linux/c/f08adf5add9a071160c68bb2a61d697f39ab0758

This is the "original fix", a v5.16 commit, which was backported to all
the stables. For this case, that seems fine (it's pretty easy to grep
the stable trees for the SHA).

In the case of a fix only being in -stable, what will be listed for
SHAs here? Each stable SHA? Something else?
  

On Thu, Feb 15, 2024 at 11:40:43AM -0800, Kees Cook wrote:
> On Thu, Feb 15, 2024 at 07:20:09PM +0100, Greg Kroah-Hartman wrote:
> > Here's an example of what the CVE announcement is going to look like for
> > a "test" that we have been doing for our scripts
> > 	https://lore.kernel.org/linux-cve-announce/2024021353-drainage-unstuffed-a7c0@gregkh/T/#u
> > ...
> > the latest release is impossible, the individual change to resolve this
> > issue can be found at:
> > 	https://git.kernel.org/stable/linux/c/f08adf5add9a071160c68bb2a61d697f39ab0758
> 
> This is the "original fix", a v5.16 commit, which was backported to all
> the stables. For this case, that seems fine (it's pretty easy to grep
> the stable trees for the SHA).
> 
> In the case of a fix only being in -stable, what will be listed for
> SHAs here? Each stable SHA? Something else?

I think listing all of the SHA values, stable and mainline, would be
best, right?  No need for everyone to try to grep the trees, and bonus,
the json format has a specific field just for this as well.  That's on
my todo list for today...

thanks,

greg k-h
  

On Thu, 15 Feb 2024, Vegard Nossum <vegard.nossum@oracle.com> wrote:
> On 15/02/2024 12:50, Greg Kroah-Hartman wrote:
>> On Wed, Feb 14, 2024 at 09:37:31AM +0100, Vegard Nossum wrote:
>>> Document titles should have ==== above them as well, and then you would
>>> need to shift all the other headings in this document (i.e. all the ---
>>> should become ===).
>>>
>>> Info here: https://docs.kernel.org/doc-guide/sphinx.html#specific-guidelines-for-the-kernel-documentation
>> 
>> Really?  I copied this directly from
>> Documentation/process/security-bugs.rst which is in the format that I
>> used here.  Which one is incorrect, I'm confused.
>
> Documentation/ currently has a mix of both formats and they both work,
> but the guidelines linked above is the gold standard and what we should
> aim for in new documents.
>
> The "correct" format would thus be:
>
> ====
> CVEs
> ====
>
> ...
>
> Process
> =======
>
> ...
>
> At least this is my understanding; I'm happy to be corrected (and in
> this case, we should also update the documentation).

rst basically allows any order of the heading underlines, and their
relative hierarchy is determined by how they show up in each document,
it's not specified by rst. However, it would be much easier for everyone
if all the kernel documents followed the same style.

BR,
Jani.
  

On Fri, Feb 16, 2024 at 10:28:39AM +0200, Jani Nikula wrote:
> On Thu, 15 Feb 2024, Vegard Nossum <vegard.nossum@oracle.com> wrote:
> > On 15/02/2024 12:50, Greg Kroah-Hartman wrote:
> >> On Wed, Feb 14, 2024 at 09:37:31AM +0100, Vegard Nossum wrote:
> >>> Document titles should have ==== above them as well, and then you would
> >>> need to shift all the other headings in this document (i.e. all the ---
> >>> should become ===).
> >>>
> >>> Info here: https://docs.kernel.org/doc-guide/sphinx.html#specific-guidelines-for-the-kernel-documentation
> >> 
> >> Really?  I copied this directly from
> >> Documentation/process/security-bugs.rst which is in the format that I
> >> used here.  Which one is incorrect, I'm confused.
> >
> > Documentation/ currently has a mix of both formats and they both work,
> > but the guidelines linked above is the gold standard and what we should
> > aim for in new documents.
> >
> > The "correct" format would thus be:
> >
> > ====
> > CVEs
> > ====
> >
> > ...
> >
> > Process
> > =======
> >
> > ...
> >
> > At least this is my understanding; I'm happy to be corrected (and in
> > this case, we should also update the documentation).
> 
> rst basically allows any order of the heading underlines, and their
> relative hierarchy is determined by how they show up in each document,
> it's not specified by rst. However, it would be much easier for everyone
> if all the kernel documents followed the same style.

Agreed, someone should pick a style and sweep the whole directory and
sync them up to the agreed formatting. :)

thanks,

greg k-h
  

On Thu, Feb 15, 2024 at 07:36:20PM +0100, Michal Hocko wrote:
> On Thu 15-02-24 19:20:09, Greg KH wrote:
> > On Thu, Feb 15, 2024 at 06:54:17PM +0100, Michal Hocko wrote:
> > > On Wed 14-02-24 09:00:30, Greg KH wrote:
> > > [...]
> > > > +Process
> > > > +-------
> > > > +
> > > > +As part of the normal stable release process, kernel changes that are
> > > > +potentially security issues are identified by the developers responsible
> > > > +for CVE number assignments and have CVE numbers automatically assigned
> > > > +to them.  These assignments are published on the linux-cve-announce
> > > > +mailing list as announcements on a frequent basis.
> > > > +
> > > > +Note, due to the layer at which the Linux kernel is in a system, almost
> > > > +any bug might be exploitable to compromise the security of the kernel,
> > > > +but the possibility of exploitation is often not evident when the bug is
> > > > +fixed.  Because of this, the CVE assignment team is overly cautious and
> > > > +assign CVE numbers to any bugfix that they identify.  This
> > > > +explains the seemingly large number of CVEs that are issued by the Linux
> > > > +kernel team.
> > > 
> > > Does the process focus only on assigning CVE numbers to a given upstream
> > > commit(s) withou any specifics of the actual security threat covered by
> > > the said CVE?
> > 
> > Outside of the git commit text, no, we are not going to be adding
> > anything additional to the report, UNLESS someone wants to add
> > additional text to it, and then we will be glad to update a CVE entry
> > with the additional information.
> 
> OK, so what is the point of having CVE assigned to such a commit without
> any addional information which is already referenced by the kernel sha?
> What is the actual added value of that CVE?

It provides the proper signal to others that "hey, this is a
vulnerability that you might want to take if it affects you".  Right now
we are fixing lots and lots of things and no one notices as their
"traditional" path of only looking at CVEs for the kernel is totally
incorrect.

> > Here's an example of what the CVE announcement is going to look like for
> > a "test" that we have been doing for our scripts
> > 	https://lore.kernel.org/linux-cve-announce/2024021353-drainage-unstuffed-a7c0@gregkh/T/#u
> 
> Thanks this gave me some idea. One worrying part is
> : Please note that only supported kernel versions have fixes applied to
> : them.  For a full list of currently supported kernel versions, please
> : see https://www.kernel.org/
> 
> >From the above it is not really clear "supported by _whom_". Because I
> am pretty sure there are _fully_ supported kernels outside of that list
> which are actively maintained.

Very true, how about this wording change:
	For a full list of currently supported kernel versions by the
	kernel developer community, please see https://www.kernel.org/

I added "by the kernel developer community", is that ok?

And as you're here, I have no objection to adding the vulnerable/fixes
info from various distros that are curently based on these same
kernel.org versions if you wish to provide them to me.  Give us a few
more days to nail down the version reporting format and then take a look
at it to see if you all can tie into that.

thanks,

greg k-h
  

On Fri 16-02-24 12:25:46, Greg KH wrote:
> On Thu, Feb 15, 2024 at 07:36:20PM +0100, Michal Hocko wrote:
> > On Thu 15-02-24 19:20:09, Greg KH wrote:
> > > On Thu, Feb 15, 2024 at 06:54:17PM +0100, Michal Hocko wrote:
> > > > On Wed 14-02-24 09:00:30, Greg KH wrote:
> > > > [...]
> > > > > +Process
> > > > > +-------
> > > > > +
> > > > > +As part of the normal stable release process, kernel changes that are
> > > > > +potentially security issues are identified by the developers responsible
> > > > > +for CVE number assignments and have CVE numbers automatically assigned
> > > > > +to them.  These assignments are published on the linux-cve-announce
> > > > > +mailing list as announcements on a frequent basis.
> > > > > +
> > > > > +Note, due to the layer at which the Linux kernel is in a system, almost
> > > > > +any bug might be exploitable to compromise the security of the kernel,
> > > > > +but the possibility of exploitation is often not evident when the bug is
> > > > > +fixed.  Because of this, the CVE assignment team is overly cautious and
> > > > > +assign CVE numbers to any bugfix that they identify.  This
> > > > > +explains the seemingly large number of CVEs that are issued by the Linux
> > > > > +kernel team.
> > > > 
> > > > Does the process focus only on assigning CVE numbers to a given upstream
> > > > commit(s) withou any specifics of the actual security threat covered by
> > > > the said CVE?
> > > 
> > > Outside of the git commit text, no, we are not going to be adding
> > > anything additional to the report, UNLESS someone wants to add
> > > additional text to it, and then we will be glad to update a CVE entry
> > > with the additional information.
> > 
> > OK, so what is the point of having CVE assigned to such a commit without
> > any addional information which is already referenced by the kernel sha?
> > What is the actual added value of that CVE?
> 
> It provides the proper signal to others that "hey, this is a
> vulnerability that you might want to take if it affects you".

OK, but stating that something is a vulnerability fix requires a proper
analysis and this is a non trivial work. The wording here indicates that
most of the fixes will gain their CVE. The existing process really sucks
because there are just too many CVEs which really do not have any
security implications but it seems that the new process is not going to
address that because it will likely generate even more CVEs.

> Right now
> we are fixing lots and lots of things and no one notices as their
> "traditional" path of only looking at CVEs for the kernel is totally
> incorrect.

Right, there are quite a lot of people who consider CVE fixes much more
important than regular fixes. Their reasoning might be completely
misleading but there might be very good reasons to stick to minimalistic
approach, e.g. to reduce risk of regressions.

I believe it is perfectly fair to say that whoever relies on stable
kernels support needs to update to the latest stable kernel version to
be covered by security and functional fixes. On the other hand I do not
think it is an improvement to the process to swamp CVE database with any
random fixes without a proper evaluation. If the kernel community
doesn't believe in the CVE process then fair enough, just do not assign
them unless you want to explicitly call out fixes with a high impact
security implications. Having fewer good quality CVEs would definitely
improve the process.

> > > Here's an example of what the CVE announcement is going to look like for
> > > a "test" that we have been doing for our scripts
> > > 	https://lore.kernel.org/linux-cve-announce/2024021353-drainage-unstuffed-a7c0@gregkh/T/#u
> > 
> > Thanks this gave me some idea. One worrying part is
> > : Please note that only supported kernel versions have fixes applied to
> > : them.  For a full list of currently supported kernel versions, please
> > : see https://www.kernel.org/
> > 
> > >From the above it is not really clear "supported by _whom_". Because I
> > am pretty sure there are _fully_ supported kernels outside of that list
> > which are actively maintained.
> 
> Very true, how about this wording change:
> 	For a full list of currently supported kernel versions by the
> 	kernel developer community, please see https://www.kernel.org/
> 
> I added "by the kernel developer community", is that ok?

That sound much better!
 
> And as you're here, I have no objection to adding the vulnerable/fixes
> info from various distros that are curently based on these same
> kernel.org versions if you wish to provide them to me.

I cannot speak for distro kernels in general. I can tell you that we at
Suse do not base our product kernels on stable trees and we
carefully evaluate backports we commit to support.
  

On Fri, Feb 16, 2024 at 02:20:04PM +0100, Michal Hocko wrote:
> > Right now
> > we are fixing lots and lots of things and no one notices as their
> > "traditional" path of only looking at CVEs for the kernel is totally
> > incorrect.
> 
> Right, there are quite a lot of people who consider CVE fixes much more
> important than regular fixes. Their reasoning might be completely
> misleading but there might be very good reasons to stick to minimalistic
> approach, e.g. to reduce risk of regressions.
> 
> I believe it is perfectly fair to say that whoever relies on stable
> kernels support needs to update to the latest stable kernel version to
> be covered by security and functional fixes. On the other hand I do not
> think it is an improvement to the process to swamp CVE database with any
> random fixes without a proper evaluation. If the kernel community
> doesn't believe in the CVE process then fair enough, just do not assign
> them unless you want to explicitly call out fixes with a high impact
> security implications. Having fewer good quality CVEs would definitely
> improve the process.

As you know, it's almost impossible to determine if a fix is "high
impact" or not, given that we have no idea what anyone's use case is for
the kernel.  We have documented proof of single-byte-buffer-overflows
resulting in complete system takeovers, and the same for very tiny
use-after-free issues, and the same for tiny "overflow a USB string
buffer" issues, and so on.

So as always, we need to treat "a bug is a bug is a bug" and when
looking at the bug fix, if it resolves something that is known to be
a vulnerability (again, as defined by CVE themselves), then we need to
mark it as such.

If you find that we are marking things as a CVE thatt you do not feel
should be marked as such, please let us know and we will be glad to
discuss it on a case-by-case basis.

But note, this type of classification has been happening for the kernel
stable commits for 2+ years now, by Sasha, in the GSD records, so this
isn't something new that we have been doing, it's just that only a very
small group were noticing that, and now a larger one might notice this.

thanks,

greg k-h
  

On Fri 16-02-24 16:34:57, Greg KH wrote:
> On Fri, Feb 16, 2024 at 02:20:04PM +0100, Michal Hocko wrote:
> > > Right now
> > > we are fixing lots and lots of things and no one notices as their
> > > "traditional" path of only looking at CVEs for the kernel is totally
> > > incorrect.
> > 
> > Right, there are quite a lot of people who consider CVE fixes much more
> > important than regular fixes. Their reasoning might be completely
> > misleading but there might be very good reasons to stick to minimalistic
> > approach, e.g. to reduce risk of regressions.
> > 
> > I believe it is perfectly fair to say that whoever relies on stable
> > kernels support needs to update to the latest stable kernel version to
> > be covered by security and functional fixes. On the other hand I do not
> > think it is an improvement to the process to swamp CVE database with any
> > random fixes without a proper evaluation. If the kernel community
> > doesn't believe in the CVE process then fair enough, just do not assign
> > them unless you want to explicitly call out fixes with a high impact
> > security implications. Having fewer good quality CVEs would definitely
> > improve the process.
> 
> As you know, it's almost impossible to determine if a fix is "high
> impact" or not, given that we have no idea what anyone's use case is for
> the kernel.  We have documented proof of single-byte-buffer-overflows
> resulting in complete system takeovers, and the same for very tiny
> use-after-free issues, and the same for tiny "overflow a USB string
> buffer" issues, and so on.

Right, generally speaking this is not an easy task. It requires a lot of
diligence actually. Sometimes there is no clear cut and that is _fine_.
The CVE system cannot ever be bullet proof and mark every single
security related fix (really you can be creating new security problems
just by backporting upstream fixes into stable trees).

But that is not really all that important, the main thing/question is
whether it can be _useful_. If you simply assign CVE to any fix in
stable you end up with thousands of CVEs and I really fail to see any
practical benefit from that. Well, unless you want to DoS the system and
its consumers. Who do you expect to be the user/consumer of those CVE
numbers? You have already said that community supported stable kernels
mandate the latest version to be used. Those users do not need to know
there is $BIG_NUMBER of CVEs in them.

If you want to mark a specific class of fixes with CVE because they are
known to be used for exploits then fine! That is something actually
useful. If you allow users to explicitly mark a fix as security relevant
because of XYZ argument then really great!

> So as always, we need to treat "a bug is a bug is a bug" and when
> looking at the bug fix, if it resolves something that is known to be
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> a vulnerability (again, as defined by CVE themselves), then we need to
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> mark it as such.

I am completely with you on that! That is quite far away from what the
documentation says AFAICS.
 
> If you find that we are marking things as a CVE thatt you do not feel
> should be marked as such, please let us know and we will be glad to
> discuss it on a case-by-case basis.

I've been through that exercise with the CVE process over years many
times. It has always been a pain because you were not talking to domain
experts who could evaluate the reasoning behind the dispute. I consider
the new process of a clearly defined dispute process a big improvement!
But if the real practice would be thousands of CVEs created for any
stable backport then this will DoS many existing CVE consumers.

All that being said. I do agree that taking control of CVEs and making
that kernel community thing is a good thing! But I really fail to
understand how increasing the number of CVEs by nominating all/most
stable fixes is going to help anybody or improve the existing process.

Thanks!