Re: [PATCH] docs: stable-kernel-rules: mention Rust soundness issues

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Oct 20, 2026 at 06:33:58PM +0200, Miguel Ojeda wrote:
> Back in 2023 I asked the stable kernel team whether we could consider
> Rust soundness issues for backporting, since we wanted to be able to
> protect (as much as possible) downstream users of stable kernels.
> 
> Since then, we have been doing our best to backport patches for Rust
> soundness issues.
> 
> After the Rust experiment ended, I documented it in the "Submit checklist
> addendum" in our "Subsystem Profile document" [1] (i.e. `P:` entry in
> `MAINTAINERS`):
> 
>     #### Soundness issues and backporting
> 
>     In general, fixes for Rust soundness issues should be marked for
>     backport, unless there is a reason not to (such as situations where
>     the backport may require a lot of effort but the risk of users
>     hitting UB is low).
> 
>     For context, while the stable kernel rules mention "theoretical
>     issues" should not be backported (which one could argue Rust soundness
>     issues are if no existing users hit UB), we discussed the topic of
>     Rust soundness issues with the stable team and decided that we would
>     do our best to backport them.
> 
>     The goal is to help to prevent actual issues for downstream users,
>     distributions and vendors that patch the kernel further or even
>     add completely new code on top, since those modifications could
>     hit UB. In other words, the idea is to maintain the "extra layer"
>     of protection in stable kernels too, as much as reasonably possible.
> 
> Thus make it clearer by briefly mentioning it as well in the stable
> kernel rules.
> 
> Link: https://rust-for-linux.com/contributing#soundness-issues-and-backporting [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> As requested, here is the following embedded patch as an independent
> thread:
> 
>   https://lore.kernel.org/all/20261016160030.118973-1-ojeda@kernel.org/
> 
> I added a small paragraph above to make it clear it is what we have been
> doing in practice since then.
> 
>  Documentation/process/stable-kernel-rules.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
> index edf90bbe30f4..ffa7905543a6 100644
> --- a/Documentation/process/stable-kernel-rules.rst
> +++ b/Documentation/process/stable-kernel-rules.rst
> @@ -17,7 +17,7 @@ Rules on what kind of patches are accepted, and which ones are not, into the
> 
>    - It fixes a problem like an oops, a hang, data corruption, a real security
>      issue, a hardware quirk, a build error (but not for things marked
> -    CONFIG_BROKEN), or some "oh, that's not good" issue.
> +    CONFIG_BROKEN), a Rust soundness issue, or some "oh, that's not good" issue.
>    - Serious issues as reported by a user of a distribution kernel may also
>      be considered if they fix a notable performance or interactivity issue.
>      As these fixes are not as obvious and have a higher risk of a subtle
> 
> base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
> --
> 2.56.0

Looks good, thanks, I'll queue this up after my first batch of -rc1
patches get merged.

greg k-h