[PATCH] docs: cve: Describe how security fixes reach users

[PATCH] docs: cve: Describe how security fixes reach users

[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.

Link: https://lore.kernel.org/all/2026110719-zipping-silliness-2443@gregkh/
Link: https://lore.kernel.org/all/2026111052-spectator-legwarmer-4c1e@gregkh/
Signed-off-by: Kees Cook <kees@kernel.org>
---
 Documentation/process/cve.rst | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst
index 5e2753eff729..d16b5c2bf7ba 100644
--- a/Documentation/process/cve.rst
+++ b/Documentation/process/cve.rst
@@ -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.
-- 
2.55.0

Re: [PATCH] docs: cve: Describe how security fixes reach users

[Greg Kroah-Hartman]

On Tue, Nov 10, 2026 at 05:44:23PM -0800, Kees Cook wrote:
> 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.
> 
> Link: https://lore.kernel.org/all/2026110719-zipping-silliness-2443@gregkh/
> Link: https://lore.kernel.org/all/2026111052-spectator-legwarmer-4c1e@gregkh/
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
>  Documentation/process/cve.rst | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst
> index 5e2753eff729..d16b5c2bf7ba 100644
> --- a/Documentation/process/cve.rst
> +++ b/Documentation/process/cve.rst
> @@ -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.
> -- 
> 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

Re: [PATCH] docs: cve: Describe how security fixes reach users

[Thorsten Leemhuis]

On 11/11/26 02:44, Kees Cook wrote:
> 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.
> 
> Link: https://lore.kernel.org/all/2026110719-zipping-silliness-2443@gregkh/
> Link: https://lore.kernel.org/all/2026111052-spectator-legwarmer-4c1e@gregkh/
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
>  Documentation/process/cve.rst | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst
> index 5e2753eff729..d16b5c2bf7ba 100644
> --- a/Documentation/process/cve.rst
> +++ b/Documentation/process/cve.rst
> @@ -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