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@xxxxxxxxxx>
> ---
>  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