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

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

[Miguel Ojeda]

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

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

[Greg Kroah-Hartman]

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