docs: cve: Describe how security fixes reach users
Subsystems (3)
PATCH 1/1 docs: cve: Describe how security fixes reach users
Recent threads on kernel-hardening proposed new mechanisms for mitigating kernel CVEs while waiting for distributions to ship their fixes. The CVE documentation does not say how fixes reach users, or whose job it is to get them into a vendor's kernel. Add a section that does, summarizing the answers given in those threads.
--- Documentation/process/cve.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
Documentation/process/cve.rst +30 -0
@@ -119,3 +119,33 @@ 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. +Getting security fixes +====================== + +Fixes for security issues reach users the same way as every other +fix: through the stable and longterm kernel releases listed at +https://kernel.org/releases.html. These are released frequently, each +one tested as a whole by many community members. The CVE assignment team +announces these fixes on the linux-cve-announce mailing list, +and only once a fix is in a stable kernel tree, so the fix is already +available when its CVE is announced, and no vendor learns of a CVE before +anyone else (except for the very rare case of :ref:`embargoed flaws +<process/security-bugs:Disclosure and embargoed information>`, +which do not include :ref:`AI-discovered flaws +<process/security-bugs:What qualifies as a security bug>`). +All of this is available to everyone, at no cost. + +The best response to a CVE, and the quickest way to receive its fix, is +to run one of those kernels and keep updating it. A kernel version +that is no longer supported there only gets a fix after someone +backports it, and that work is done outside the kernel community. + +If your kernel comes from a Linux distribution or another vendor, +getting fixes into it is that vendor's responsibility. The kernel +developers and stable maintainers publish the fixes, but they do not +integrate them into each vendor's kernel. If fixes reach you later +than you need them, raise it with your vendor, particularly if you pay +them for support, since keeping your kernel up to date and secure is +part of what that support provides. If your vendor cannot keep up, +some distributions follow the stable releases closely and ship their +fixes promptly, also at no cost.
Signature · 1 line
2.55.0
Quoted 54 lines · Kees Cook
Recent threads on kernel-hardening proposed new mechanisms for mitigating kernel CVEs while waiting for distributions to ship their fixes. The CVE documentation does not say how fixes reach users, or whose job it is to get them into a vendor's kernel. Add a section that does, summarizing the answers given in those threads.
Signed-off-by Kees Cook <[email protected]>--- Documentation/process/cve.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)Documentation/process/cve.rst +30
-0@@ -119,3 +119,33 @@ 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. +Getting security fixes +====================== + +Fixes for security issues reach users the same way as every other +fix: through the stable and longterm kernel releases listed at +https://kernel.org/releases.html. These are released frequently, each +one tested as a whole by many community members. The CVE assignment team +announces these fixes on the linux-cve-announce mailing list, +and only once a fix is in a stable kernel tree, so the fix is already +available when its CVE is announced, and no vendor learns of a CVE before +anyone else (except for the very rare case of :ref:`embargoed flaws +<process/security-bugs:Disclosure and embargoed information>`, +which do not include :ref:`AI-discovered flaws +<process/security-bugs:What qualifies as a security bug>`). +All of this is available to everyone, at no cost. + +The best response to a CVE, and the quickest way to receive its fix, is +to run one of those kernels and keep updating it. A kernel version +that is no longer supported there only gets a fix after someone +backports it, and that work is done outside the kernel community. + +If your kernel comes from a Linux distribution or another vendor, +getting fixes into it is that vendor's responsibility. The kernel +developers and stable maintainers publish the fixes, but they do not +integrate them into each vendor's kernel. If fixes reach you later +than you need them, raise it with your vendor, particularly if you pay +them for support, since keeping your kernel up to date and secure is +part of what that support provides. If your vendor cannot keep up, +some distributions follow the stable releases closely and ship their +fixes promptly, also at no cost.Signature · 1 line
2.55.0
Thanks for documenting this. Hopefully the companies that don't keep up to date kernels will get the proper pushback from their customers to fix their release processes...
greg k-h
Quoted 18 lines · Kees Cook
Recent threads on kernel-hardening proposed new mechanisms for mitigating kernel CVEs while waiting for distributions to ship their fixes. The CVE documentation does not say how fixes reach users, or whose job it is to get them into a vendor's kernel. Add a section that does, summarizing the answers given in those threads.
Signed-off-by Kees Cook <[email protected]>--- Documentation/process/cve.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)Documentation/process/cve.rst +0
-0
Documentation/process/cve.rst assigned to all fixes for all issues, but sometimes we will fail to · line 126
Quoted 9 lines
Documentation/process/cve.rst +5
-0@@ -119,3 +119,33 @@ 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. +Getting security fixes +====================== + +Fixes for security issues reach users the same way as every other +fix: through the stable and longterm kernel releases listed at
I found a few things expressed slightly too complicated. I first wanted to point that out, but then decided to just suggest something better. Not sure myself if I like the result. If you do and want to take it, let me know, then I will polish it a bit more.
"""
Getting security fixes
======================
All fixes for vulnerabilities are first resolved in Linux' main development branch and then reach users like any other fix: through backports to one of the currently supported stable and longterm kernel series, which https://kernel.org/ lists. New versions of those series are released frequently, each one tested as a whole by many community members. Only once a fix is in a stable/longterm kernel release, the CVE assignment team announces the CVE on the linux-cve-announce mailing list. No vendor thus learns of those before anyone else -- except for the very rare case of :ref:embargoed flaws <process/security-bugs:Disclosure and embargoed information>, which do not include :ref:AI-discovered flaws <process/security-bugs:What qualifies as a security bug>.
All of this is available to everyone at no cost. The best response to a CVE and the quickest way to receive its fix is to always quickly switch to the latest release from one of those stable/longterm kernel series, as then you will frequently receive security fixes even before CVEs are published.
Some Linux distributions or hardware vendors regularly distribute those new stable/longterm releases as updates within days of their release at no cost -- and thereby distribute fixes to their users. But if your vendor does not regularly ship those releases or even bases its kernel on a series that is not supported anymore, it is that vendor's responsibility to integrate the fixes -- if those reach you later than you need them, raise it with your vendor, particularly if you pay them for support, since keeping your kernel up to date and secure is part of what that support provides.
"""
Wondering if we should mention what "EOL" on kernel.org means -- and that some CVE fixes are not backported to older series and suggest something like Greg did here:
http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/
Ciao, Thorsten