linux-kernel - Re: [PATCH 3/3] rust: error: replace `WARN_ON_ONCE` comment with `debug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2025090325-drinking-illusion-ef3d@gregkh>
Date: Wed, 3 Sep 2025 11:45:58 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Danilo Krummrich <dakr@...nel.org>, rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [PATCH 3/3] rust: error: replace `WARN_ON_ONCE` comment with
 `debug_assert!`

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@...uxfoundation.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