`warn_on!` support landed recently, and we had a very old comment
about using it when supported to catch invalid inputs passed to
`Error::from_errno`.

However, the kernel policy is that reaching a `WARN_ON` by user
interactions is a CVE, e.g. [1].

Since `from_errno` and other functions that use it such as `to_result`
will be used everywhere, sooner or later a caller may pass an invalid
value due to a user interaction.

Thus, instead, use a debug assertion -- this assumes hitting one of them
is not going to be considered a CVE (which requires
`CONFIG_RUST_DEBUG_ASSERTIONS=y`).

We don't want to potentially panic when testing the examples, thus
convert those to a build-test.

Cc: Greg KH <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/all/2024092340-renovate-cornflake-4b5e@gregkh/ [1]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 rust/kernel/error.rs | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/rust/kernel/error.rs b/rust/kernel/error.rs
index 1ebdb798fd5d..7b9892a46505 100644
--- a/rust/kernel/error.rs
+++ b/rust/kernel/error.rs
@@ -115,18 +115,20 @@ impl Error {
     /// The following calls are considered a bug:
     ///
     /// ```
+    /// # fn no_run() {
     /// assert_eq!(Error::from_errno(0), EINVAL);
     /// assert_eq!(Error::from_errno(-1000000), EINVAL);
+    /// # }
     /// ```
     pub fn from_errno(errno: crate::ffi::c_int) -> Error {
         if let Some(error) = Self::try_from_errno(errno) {
             error
         } else {
-            // TODO: Make it a `WARN_ONCE` once available.
             crate::pr_warn!(
                 "attempted to create `Error` with out of range `errno`: {}\n",
                 errno
             );
+            debug_assert!(false);
             code::EINVAL
         }
     }
-- 
2.51.0

On Fri, Aug 29, 2025 at 9:23 PM Miguel Ojeda <ojeda@kernel.org> wrote:
>
> Thus, instead, use a debug assertion -- this assumes hitting one of them
> is not going to be considered a CVE (which requires
> `CONFIG_RUST_DEBUG_ASSERTIONS=y`).

Greg: RFC on this -- this is the usual conundrum around `WARN`. I
would like to have an assertion or `WARN`-like entity for developers
that doesn't imply CVEs when hit by user interactions. More generally,
to know that such a config option is OK as long as it is labeled
clearly a debug one like this one (we can document the CVE bit
explicitly if needed).

Thanks!

Cheers,
Miguel

On Fri, Aug 29, 2025 at 09:43:24PM +0200, Miguel Ojeda wrote:
> On Fri, Aug 29, 2025 at 9:23 PM Miguel Ojeda <ojeda@kernel.org> wrote:
> >
> > Thus, instead, use a debug assertion -- this assumes hitting one of them
> > is not going to be considered a CVE (which requires
> > `CONFIG_RUST_DEBUG_ASSERTIONS=y`).
> 
> Greg: RFC on this -- this is the usual conundrum around `WARN`. I
> would like to have an assertion or `WARN`-like entity for developers
> that doesn't imply CVEs when hit by user interactions. More generally,
> to know that such a config option is OK as long as it is labeled
> clearly a debug one like this one (we can document the CVE bit
> explicitly if needed).

I do not understand, if there is ANY way that a user can trigger a
WARN() call, then that is considered a "vulnerability" as far as CVE is
concerned and so I need to issue one when it is fixed.  This is entirely
because the panic-on-warn option could have also been enabled.

If you wish to state that CONFIG_RUST_DEBUG_ASSERTIONS=y should NEVER be
used in ANY shipping Linux system, then yes, we can carve out an
exception for this (we do that if lockdep is enabled as that should
never be in a running system, only a development one).  But I thought
that some groups wanted to have that option enabled in their running
systems to provide additional security overall?

And yes, the fact that enabling an option for safety can actually cause
a CVE to be issued is not lost on me as being very odd :)

thanks,

greg k-h

On Sat, Aug 30, 2025 at 8:28 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> If you wish to state that CONFIG_RUST_DEBUG_ASSERTIONS=y should NEVER be
> used in ANY shipping Linux system, then yes, we can carve out an
> exception for this (we do that if lockdep is enabled as that should
> never be in a running system, only a development one).

The config option is meant for development purposes ("debug"). We
don't control all its behavior anyway, because the compiler/stdlib
will also add many assertions (e.g. for unsafe preconditions). So, for
instance, it could easily have a non-trivial performance impact.

For the same reason, it will also change behavior depending on the
compiler version. So, for instance, new assertions in new compiler
versions could have an impact that is not seen in previous versions.

Thus, for this particular config option, we cannot guarantee much, and
the help text already states "This can be used to enable extra
debugging code in development but not in production.".

Having said that, I regularly CI-test our main branches with the
option enabled, and it has worked fine so far.

So if a user actually run with such kind of asserts in production,
because they really want to crash on anything and everything, I don't
see why they couldn't. It may really be that it actually stops an
important exploit from going on. Of course, it may also be that it
elevates a trivial bug into a denial of service elsewhere, but that
risk may be worth it for certain users.

In fact, I would say it is a good thing that certain specialized users
run with it enabled, because then it means they may find potential
bugs for others, and that makes everyone safer in practice.

But I don't know what exact constraints the CVE system puts on you, so
it is hard to assess what the best wording for such an option would
be.

As an addendum: the fact that the compiler is involved is a bit
tangential -- we could have our own "debug" asserts (or "extra
paranoid" asserts) that are independent of the compiler, and we could
have a separate config option etc. But, of course, in this case with
the compiler/stdlib involved it means it is harder to
blanket-recommend for production.

Thanks!

Cheers,
Miguel

On Sat, Aug 30, 2025 at 01:07:52PM +0200, Miguel Ojeda wrote:
> On Sat, Aug 30, 2025 at 8:28 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > If you wish to state that CONFIG_RUST_DEBUG_ASSERTIONS=y should NEVER be
> > used in ANY shipping Linux system, then yes, we can carve out an
> > exception for this (we do that if lockdep is enabled as that should
> > never be in a running system, only a development one).
> 
> The config option is meant for development purposes ("debug"). We
> don't control all its behavior anyway, because the compiler/stdlib
> will also add many assertions (e.g. for unsafe preconditions). So, for
> instance, it could easily have a non-trivial performance impact.
> 
> For the same reason, it will also change behavior depending on the
> compiler version. So, for instance, new assertions in new compiler
> versions could have an impact that is not seen in previous versions.
> 
> Thus, for this particular config option, we cannot guarantee much, and
> the help text already states "This can be used to enable extra
> debugging code in development but not in production.".
> 
> Having said that, I regularly CI-test our main branches with the
> option enabled, and it has worked fine so far.
> 
> So if a user actually run with such kind of asserts in production,
> because they really want to crash on anything and everything, I don't
> see why they couldn't. It may really be that it actually stops an
> important exploit from going on. Of course, it may also be that it
> elevates a trivial bug into a denial of service elsewhere, but that
> risk may be worth it for certain users.
> 
> In fact, I would say it is a good thing that certain specialized users
> run with it enabled, because then it means they may find potential
> bugs for others, and that makes everyone safer in practice.
> 
> But I don't know what exact constraints the CVE system puts on you, so
> it is hard to assess what the best wording for such an option would
> be.

There are no "constraints" only a definition of a vulnerability that we
must follow.  And for that, any way that a user could cause a reboot or
panic, without having root privileges, gets assigned a CVE.

One exception being if lockdep or a few other "debugging only" options
are enabled.  Those are explicitly stated by their maintainers that they
should NEVER be enabled in a real system.  For those we do not assign
CVEs as they should never be actually triggered by a user.

So I don't know what to recommend here.  I strongly advise against
adding code to the kernel that can cause users to reboot their boxes if
they do something.  But hey, if developers want to do that, I'll gladly
assign CVEs for when it happens :)

thanks,

greg k-h

On Wed, Sep 3, 2025 at 11:46 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> There are no "constraints" only a definition of a vulnerability that we
> must follow.  And for that, any way that a user could cause a reboot or
> panic, without having root privileges, gets assigned a CVE.
>
> One exception being if lockdep or a few other "debugging only" options
> are enabled.  Those are explicitly stated by their maintainers that they
> should NEVER be enabled in a real system.  For those we do not assign
> CVEs as they should never be actually triggered by a user.
>
> So I don't know what to recommend here.  I strongly advise against
> adding code to the kernel that can cause users to reboot their boxes if
> they do something.  But hey, if developers want to do that, I'll gladly
> assign CVEs for when it happens :)

Sounds good to me, thanks.

These are meant to be debug assertions, so it should be fine. We can
be more explicit in the wording of the config option.

Cheers,
Miguel