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 <[email protected]>
Reviewed-by: Konstantin Ryabitsev <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Reviewed-by: Lukas Bulwahn <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
---
v4: Add MAINTAINER entry
Lots of tiny wording changes based on many reviews
Collected some Reviewed-by: tags
Fixed documenation build by properly referencing the security
process documentation file.
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 +-
MAINTAINERS | 5 +
4 files changed, 128 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..6b244d938694
--- /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 individuals and companies
+outside of the kernel community has made it clear that the kernel
+community should have control over those assignments.
+
+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
+<https://subspace.kernel.org/subscribing.html>`_ 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,
+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 <[email protected]>
+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 <[email protected]> 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/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 <[email protected]> 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 will fail to
+notice fixes, therefore assume that some changes without a CVE assigned
+might be 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
-------------------------
diff --git a/MAINTAINERS b/MAINTAINERS
index 73d898383e51..4d05ac516ded 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5610,6 +5610,11 @@ S: Maintained
F: Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
F: drivers/net/can/ctucanfd/
+CVE ASSIGNMENT CONTACT
+M: CVE Assignment Team <[email protected]>
+S: Maintained
+F: Documentation/process/cve.rst
+
CW1200 WLAN driver
S: Orphan
F: drivers/net/wireless/st/cw1200/
--
2.43.1
On Thu, 15 Feb 2024, 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.
There is still one thing that's not clear to me with this new process, and
that's how embargos are going to be handled.
Currently, the process is broken as well, but at least understood by
everybody.
- issues are reported to [email protected]. No CVE assigned, 7days
embargo, then fix gets pushed out
- at some point (in parallel, before, or after the above), the issue gets
reported to linux-distros@. CVE gets assigned, and downstreams start
integrating the fix (once available) to their codebase.
- embargo is lifted, fixes are released with proper CVE reference
How is the new process going to look like? Please keep in mind that
linux-stable is (by far!) *not* the only downstream of Linux Kernel
project.
We've had this discussion in other contexts already, but I whole-heartedly
believe that it's in no way in the Linux Kernel project's interest to kill
those other downstreams (read: Linux distros) (*) ... or is it?
(*) just looking at how much those not-basing-on-stable distros are
contributing to mainline
Thanks,
--
Jiri Kosina
SUSE Labs
On Thu, Feb 15, 2024 at 04:03:02PM +0100, J?rgen Gro? wrote:
> On 15.02.24 13:10, 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 <[email protected]>
> > Reviewed-by: Konstantin Ryabitsev <[email protected]>
> > Reviewed-by: Krzysztof Kozlowski <[email protected]>
> > Reviewed-by: Lukas Bulwahn <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > Signed-off-by: Sasha Levin <[email protected]>
> > Signed-off-by: Lee Jones <[email protected]>
> > ---
> > v4: Add MAINTAINER entry
> > Lots of tiny wording changes based on many reviews
> > Collected some Reviewed-by: tags
> > Fixed documenation build by properly referencing the security
> > process documentation file.
> > 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 +-
> > MAINTAINERS | 5 +
> > 4 files changed, 128 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..6b244d938694
> > --- /dev/null
> > +++ b/Documentation/process/cve.rst
> > @@ -0,0 +1,120 @@
>
> ...
>
> > +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 <[email protected]> so that they can work to
> > +invalidate such entries through the CNA remediation process.
>
> Today we (the Xen security team) are allocating CVEs for Xen-related
> kernel security bugs.
>
> Does this mean we should do that via [email protected] in future, or are
> you happy us continuing our process as today? If the latter, I think
> this should be noted somehow in this document in order to avoid complaints
> regarding CVEs allocated by us.
>
>
> Juergen (on behalf of the Xen security team)
That's a good question, and from what I can tell for the "rules" here,
yes, we need to coordinate somehow for anything that is Linux
kernel-only. Just email us and ask us for an id and our tools can take
it from there for the submission and other stuff, so hopefully this will
make things easier.
For stuff that crosses both sides (Xen and Linux), you are free to
create your own CVE and then use that identifier in the kernel patch
like you have in the past as I would consider Xen being the "primary"
CNA, don't you?
Is that ok? We want to make this as easy as possible, so I don't want
to get in the way of your existing process if at all possible.
thanks,
greg k-h
On Thu, Feb 15, 2024 at 06:38:05PM +0100, Jiri Kosina wrote:
> On Thu, 15 Feb 2024, 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.
>
> There is still one thing that's not clear to me with this new process, and
> that's how embargos are going to be handled.
>
> Currently, the process is broken as well, but at least understood by
> everybody.
>
> - issues are reported to [email protected]. No CVE assigned, 7days
> embargo, then fix gets pushed out
>
> - at some point (in parallel, before, or after the above), the issue gets
> reported to linux-distros@. CVE gets assigned, and downstreams start
> integrating the fix (once available) to their codebase.
linux-distros is not allowed to assign a CVE id for a Linux kernel fix,
so this will not happen here anymore. They HAVE to contact
[email protected] in order to do this as no one else is allowed to create a
CVE entry for Linux unless some very extreem things happen that I do not
plan on ever having happen to us (see the CNA rules for details.)
> - embargo is lifted, fixes are released with proper CVE reference
>
> How is the new process going to look like? Please keep in mind that
> linux-stable is (by far!) *not* the only downstream of Linux Kernel
> project.
I agree, and again, linux-distros will not be assigning CVEs for issues
that affect the currently supported kernels as listed on kernel.org, nor
will any other group, so this shouldn't be an issue as we can coordinate
properly if the above senario happens.
> We've had this discussion in other contexts already, but I whole-heartedly
> believe that it's in no way in the Linux Kernel project's interest to kill
> those other downstreams (read: Linux distros) (*) ... or is it?
I have no interest in doing anything about linux-distros, just that they
are not allowed to assign a new CVE for Linux anymore as of Tuesday this
week, and neither is any other CNA, just like they are not allowed to
assign a CVE for Windows today, no difference at all.
thanks,
greg k-h
On 15.02.24 18:49, Greg Kroah-Hartman wrote:
> On Thu, Feb 15, 2024 at 04:03:02PM +0100, Jürgen Groß wrote:
>> On 15.02.24 13:10, 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 <[email protected]>
>>> Reviewed-by: Konstantin Ryabitsev <[email protected]>
>>> Reviewed-by: Krzysztof Kozlowski <[email protected]>
>>> Reviewed-by: Lukas Bulwahn <[email protected]>
>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>> Signed-off-by: Sasha Levin <[email protected]>
>>> Signed-off-by: Lee Jones <[email protected]>
>>> ---
>>> v4: Add MAINTAINER entry
>>> Lots of tiny wording changes based on many reviews
>>> Collected some Reviewed-by: tags
>>> Fixed documenation build by properly referencing the security
>>> process documentation file.
>>> 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 +-
>>> MAINTAINERS | 5 +
>>> 4 files changed, 128 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..6b244d938694
>>> --- /dev/null
>>> +++ b/Documentation/process/cve.rst
>>> @@ -0,0 +1,120 @@
>>
>> ...
>>
>>> +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 <[email protected]> so that they can work to
>>> +invalidate such entries through the CNA remediation process.
>>
>> Today we (the Xen security team) are allocating CVEs for Xen-related
>> kernel security bugs.
>>
>> Does this mean we should do that via [email protected] in future, or are
>> you happy us continuing our process as today? If the latter, I think
>> this should be noted somehow in this document in order to avoid complaints
>> regarding CVEs allocated by us.
>>
>>
>> Juergen (on behalf of the Xen security team)
>
> That's a good question, and from what I can tell for the "rules" here,
> yes, we need to coordinate somehow for anything that is Linux
> kernel-only. Just email us and ask us for an id and our tools can take
> it from there for the submission and other stuff, so hopefully this will
> make things easier.
Okay, thanks, noted.
> For stuff that crosses both sides (Xen and Linux), you are free to
> create your own CVE and then use that identifier in the kernel patch
> like you have in the past as I would consider Xen being the "primary"
> CNA, don't you?
We didn't have this case so far, and I think we'd just have one CVE for Xen
and one for Linux. Nevertheless good to know should this case ever come up.
> Is that ok? We want to make this as easy as possible, so I don't want
> to get in the way of your existing process if at all possible.
Yes, thanks, this is okay. Just wanted to have it spelled out. :-)
Juergen
On Thu, Feb 15, 2024 at 01:10:55PM +0100, Greg Kroah-Hartman wrote:
> +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.
By this paranoid black-and-white logic, any mainline commit could have a
yet-to-be-discovered regression resulting in a catastrophic
vulnerability.
Should we stay one step ahead and just open a CVE for every mainline
commit?
Problem solved, all "vulnerabilities" have been identified! False
positives be damned!
For that matter, why don't we do as Thomas has suggested and hardcode
NR_CPUS to zero!
> 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.
How does this match up with the definition of a vulnerabilty?
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.
Bug != vulnerability. Otherwise the definition of a vulnerability would
be much simpler, i.e., "any software defect".
If a CVE is created without any analysis and doesn't describe how the
bug can be exploited then it's completely useless.
Who is this process helping?
- Not users of -stable since they already know they need to be on the
latest version.
- Not distros or their users as it's just flooding them with low quality
CVEs which have no analysis or scoring.
And enterprise distros will never be able to rebase onto -stable,
especially for older streams for which they have to be very selective,
in order to avoid destabilizing them. As you say, "a bug is a bug".
If the problem is low CVE quality then of course it makes a lot of sense
for kernel.org to become a CNA in order to take a leadership role in
helping define and improve the process for its users. But it makes no
sense to "fix" it by making CVE quality *vastly* lower by flooding
people with useless CVEs.
--
Josh
On Fri, 16 Feb 2024, Josh Poimboeuf wrote:
> - Not users of -stable since they already know they need to be on the
> latest version.
>
> - Not distros or their users as it's just flooding them with low quality
> CVEs which have no analysis or scoring.
>
> And enterprise distros will never be able to rebase onto -stable,
> especially for older streams for which they have to be very selective,
> in order to avoid destabilizing them. As you say, "a bug is a bug".
Now that you have played the distro card (thanks!) here, let me just copy
my comment from LWN where someone suggested "well, it's easy, it's the job
of the [paid] distros to do the triage" ...
The problem is, that with this new system, paid distros are going to
suffer a big time (with no benefit to anybody at all). We'll have to put a
lot of productive and creative (upstream) work on hold in order to have
enough resources to sort out the havoc that LTS team is apparently going
to create by DoSing the world with a truckload of irrelevant CVEs.
--
Jiri Kosina
SUSE Labs
On Fri, Feb 16, 2024 at 09:27:48PM +0100, Jiri Kosina wrote:
>
> Now that you have played the distro card (thanks!) here, let me just copy
> my comment from LWN where someone suggested "well, it's easy, it's the job
> of the [paid] distros to do the triage" ...
>
> The problem is, that with this new system, paid distros are going to
> suffer a big time (with no benefit to anybody at all). We'll have to put a
> lot of productive and creative (upstream) work on hold in order to have
> enough resources to sort out the havoc that LTS team is apparently going
> to create by DoSing the world with a truckload of irrelevant CVEs.
My observation is that the old system has had pretty low-quality
CVE's, and worse, overly inflated CVE Severity Scores, which has
forced all people who are supporting distro and cloud serves which
sell into the US Government market to have to do very fast releases to
meet FedRAMP requirements. At least once, I protested an overly
inflated CVSS score as being completely b.s., at a particular
enterprise distro bugzilla, and my opinion as the upstream developer
was completely ignored.
So quite frankly, at least one enteprise distro hasn't impressed me
with avoiding low quality CVE's and high CVSS scores, and so I'm quite
willing to give the new system a chance. (Especially since I've been
told that the Linux Kernel CVE team isn't planning on issuing CVSS
scores, which as far as I'm concerned, is *excellent* since my
experience is that they are quite bogus, and quite arbitrary.)
- Ted
On Fri, 16 Feb 2024, Theodore Ts'o wrote:
> My observation is that the old system has had pretty low-quality
> CVE's, and worse, overly inflated CVE Severity Scores, which has
> forced all people who are supporting distro and cloud serves which
> sell into the US Government market to have to do very fast releases to
> meet FedRAMP requirements. At least once, I protested an overly
> inflated CVSS score as being completely b.s., at a particular
> enterprise distro bugzilla, and my opinion as the upstream developer
> was completely ignored.
>
> So quite frankly, at least one enteprise distro hasn't impressed me
Sad to hear that, no matter which distro that was :), hoewer ...
> with avoiding low quality CVE's and high CVSS scores, and so I'm quite
> willing to give the new system a chance. (Especially since I've been
> told that the Linux Kernel CVE team isn't planning on issuing CVSS
> scores, which as far as I'm concerned, is *excellent* since my
> experience is that they are quite bogus, and quite arbitrary.)
.. how is this new process going to change anything in that respect?
There will always be some entity assigning a CVSS score (apparently not
the kernel.org/LTS group), and then odds are the situation you are
describing will end up happening according exactly the same scenario,
right?
I am still trying really hard to understand what exactly is the problem
this whole effort is magically solving for everybody out there either
using Linux, or producing something around/on-top-of Linux. And I still
don't get it.
Thanks,
--
Jiri Kosina
SUSE Labs