[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANiq72n-R_NaMzWtYe3430RwOpOtmxb9KP7ee5FxV+AHXGA2+g@mail.gmail.com>
Date: Wed, 3 Sep 2025 12:03:06 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
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 Wed, Sep 3, 2025 at 11:46 AM Greg KH <gregkh@...uxfoundation.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
Powered by blists - more mailing lists