[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72=eOYk=WM5xfMkHj-REYjedYiYNakVvfto-AUL5E0O8qA@mail.gmail.com>
Date: Tue, 21 Oct 2025 16:58:31 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, aliceryhl@...gle.com,
daniel.almeida@...labora.com, a.hindborg@...nel.org, alex.gaynor@...il.com,
ojeda@...nel.org, anna-maria@...utronix.de, bjorn3_gh@...tonmail.com,
boqun.feng@...il.com, frederic@...nel.org, gary@...yguo.net,
jstultz@...gle.com, linux-kernel@...r.kernel.org, lossin@...nel.org,
lyude@...hat.com, rust-for-linux@...r.kernel.org, sboyd@...nel.org,
tglx@...utronix.de, tmgross@...ch.edu,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v2 1/2] rust: add udelay() function
On Tue, Oct 21, 2025 at 4:46 PM Danilo Krummrich <dakr@...nel.org> wrote:
>
> Given that we'd have a WARN() for any value passed that is > MAX_UDELAY_MS, and
> given that WARN() is considered a vulnerability if hit (Greg, please correct me
> if that's wrong), this would literally become a vulnerability generator. :)
Yes, but only if hit in a way that can be triggered by an attacker,
e.g. user actions, not in general.
i.e. that is why I was saying that someone could end up calculating a
delay value based on something e.g. user controlled, and then gets an
edge case wrong, and hits the `WARN()`, which is the "bad case" and a
CVE would be assigned.
A `pr_warn_once!` plus `debug_assert!` (or similar) should be a fine
way for having EB in functions, which is a useful concept without
leaving it UB liek in C nor going with a full `Result`. I can document
that combo.
Cheers,
Miguel
Powered by blists - more mailing lists