linux-stable.git/rust, branch v7.2.4

rust: num: reject Bounded::shr overshifts at build time

2026-09-07T15:37:23+00:00

[ Upstream commit 223aa25aee82e188ddf043a8703b16e5fdfc37d8 ]

Make `shr` reject shifts of at least the type's bit width at build
time, instead of panicking or masking the shift amount at runtime.

[ This implies we can break the type invariant, which in turn means
  we can trigger UB via `Deref`, e.g.:

      rust_kernel: panicked at rust/kernel/num/bounded.rs:528:22:
      unsafe precondition(s) violated: hint::unreachable_unchecked must never be reached

    - Miguel ]

Signed-off-by: Eliot Courtney 
Acked-by: Alexandre Courbot 
Reviewed-by: Gary Guo 
Reviewed-by: Danilo Krummrich 
Cc: stable@vger.kernel.org
Fixes: c59a2d14cd24 ("rust: num: add `shr` and `shl` methods to `Bounded`")
Link: https://patch.msgid.link/20260810-pramin-split-v2-2-65a00b3c7309@nvidia.com
Signed-off-by: Miguel Ojeda 
Signed-off-by: Sasha Levin

kbuild: rust: keep Rust objects out of Clang LTO with inline helpers

2026-09-07T15:36:32+00:00

commit 5febf432df1cfa5b25d99b54c32103fafbdd0eb9 upstream.

Under `CONFIG_LTO_CLANG` + `CONFIG_RUST_INLINE_HELPERS`, one may hit
`objtool` errors such as:

    vmlinux.o: error: objtool: _R..._3Gsp4boot+0xd6a:
    can't find jump dest instruction at .text._R..._3Gsp4boot+0x1dfd

The reason is that in such builds, the Clang invocation that compiles
the combined Rust plus helpers bitcode emits LLVM bitcode (again) --
the final code generation happens in the linker's LTO step, which the
`-mllvm` trap options passed to Clang do not reach.

This, in turn, means that unreachable traps are missing, and the
impossible paths do not merely fallthrough to the next symbol, but past
the end of their own section, since LTO builds place each function in
its own section.

Thus filter `CC_FLAGS_LTO` out of the Clang invocation, so that it always
emits machine code directly, with the traps in place.

Assisted-by: LLM
Cc: Gary Guo 
Cc: Boqun Feng 
Cc: Alice Ryhl 
Cc: Matthew Maurer 
Cc: Josh Poimboeuf 
Cc: Peter Zijlstra 
Cc: stable@vger.kernel.org
Fixes: 3a2486cc1da5 ("kbuild: rust: provide an option to inline C helpers into Rust")
Acked-by: Gary Guo 
Link: https://patch.msgid.link/20260816133233.197500-2-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

kbuild: rust: preserve unreachable traps with inline helpers

2026-09-07T15:36:32+00:00

commit 0bff7711c19ba05ff3b686554c5a2d503c3e9797 upstream.

When `CONFIG_RUST_INLINE_HELPERS` is enabled, it is possible to hit
`objtool` warnings like:

    vmlinux.o: warning: objtool: _R..._4cmdq12CommandToGsp4init()
    falls through to next function _R..._4core5array4iter8IntoIterRShKj3_EEEBa_()

`rustc` normally emits traps for unreachable paths. However, under
`CONFIG_RUST_INLINE_HELPERS=y`, `rustc` emits LLVM bitcode and Clang
performs final code generation after the helper bitcode is linked,
but Clang does not trap unreachable IR by default.

In turn, this means `objtool` follows compiler-generated impossible Rust
`enum` paths through alignment padding into the next function, resulting
in fallthrough warnings.

Thus pass the LLVM `trap-unreachable` option to the final Clang invocation
and suppress traps immediately after `noreturn` calls, which `objtool`
already recognizes as dead ends. The combination of both flags makes it
match `rustc`'s behavior.

Rust 1.85.0 (the minimum supported one) supports LLVM >= 18, and both
flags are available in LLVM 18.

Assisted-by: LLM
Cc: Gary Guo 
Cc: Boqun Feng 
Cc: Alice Ryhl 
Cc: Matthew Maurer 
Cc: Josh Poimboeuf 
Cc: Peter Zijlstra 
Cc: stable@vger.kernel.org
Fixes: 3a2486cc1da5 ("kbuild: rust: provide an option to inline C helpers into Rust")
Acked-by: Gary Guo 
Link: https://patch.msgid.link/20260816133233.197500-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: num: restrict bool conversion to unsigned Bounded

2026-09-07T15:36:31+00:00

commit 7dd6343fc127935425a81a8f1989907996c2868d upstream.

From turns true into 1. A signed Bounded with N = 1 can hold
only -1 and 0. The current implementation can therefore create a value
that breaks Bounded's invariant. Deref relies on that invariant and
calls unreachable_unchecked() when it is broken, so safe Rust can reach
undefined behavior.

The other primitive conversions require the source and destination to
have the same signedness. Treat bool as an unsigned one-bit value and
allow conversions between bool and Bounded only when the backing integer
type is unsigned.

Fixes: 01e345e82ec3 ("rust: num: add Bounded integer wrapping type")
Closes: https://lore.kernel.org/rust-for-linux/OzuVxu0--J-9@younes.io/
Cc: stable@vger.kernel.org
Suggested-by: Alexandre Courbot 
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Younes Akhouayri 
Reviewed-by: Alexandre Courbot 
Link: https://patch.msgid.link/20260822-fix-rust-bounded-from-bool-submit-v4-1-aa780bfe7f30@younes.io
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: kernel: list: fix incorrect pop_back example comment

2026-09-07T15:36:31+00:00

commit a5c7d35e2fd3e24c411816c91f8f6cc78e652e0c upstream.

The example uses pop_back(), but the accompanying comment says
pop_front(). Update the comment to match the example.

Signed-off-by: Nikolai Grlica 
Cc: stable@vger.kernel.org
Fixes: bf87a41b85d6 ("rust: list: Add an example for `ListLinksSelfPtr` usage")
Link: https://patch.msgid.link/20260810150322.61809-1-nikolai@nikolaigrlica.dev
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: kbuild: disambiguate `zerocopy_derive` for `rusttest`

2026-09-07T15:36:31+00:00

commit 1b0bab4a873f1034c27573cfc613394cff7e0a5b upstream.

The `rustc-dev` components for Rust 1.82.0 through 1.87.0 include a
precompiled `zerocopy_derive` procedural macro in the sysroot. This
range includes Rust 1.85.0, our minimum supported version.

This makes `rusttest` fail because the compiler finds both the sysroot
copy and the copy built in `rust/test`:

    error[E0464]: multiple candidates for `dylib` dependency `zerocopy_derive` found
      --> rust/kernel/prelude.rs:70:9
       |
    70 | pub use zerocopy_derive::{
       |         ^^^^^^^^^^^^^^^
       |
       = note: candidate #1: .../lib/rustlib/x86_64-unknown-linux-gnu/lib/libzerocopy_derive-54d2b38896fa6bc5.so
       = note: candidate #2: .../rust/test/libzerocopy_derive.so

Commit fe39a233ea52 ("rust: kbuild: disambiguate `zerocopy` for
`rusttest`") fixed the equivalent ambiguity for `zerocopy`.

Thus point to the dependency explicitly in this case too.

Cc: Antoni Boucher 
Cc: stable@vger.kernel.org
Fixes: 506054980429 ("rust: zerocopy-derive: enable support in kbuild")
Link: https://patch.msgid.link/20260823193529.156066-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: devres: ensure revocation is complete before device finishes unbinding

2026-09-07T15:36:31+00:00

commit a10639966fd72fff8f7fbf3c8e733307daabd38f upstream.

Now that the revocation Completion is in place, also address the
symmetric case. When Devres::drop() wins the is_available swap and the
devres callback loses, the callback returns to devres_release_all()
without waiting. This means device unbinding can complete while
Devres::drop() is still executing drop_in_place() on another CPU, which
is a problem if T's destructor accesses device state.

Make the synchronization bidirectional. Whichever side performs
drop_in_place() signals the Completion, and the other side waits.

This does not reintroduce the nested Devres deadlock fixed by commit
ba268514ea14 ("rust: devres: fix race condition due to nesting"),
because that deadlock was caused by drop waiting for the release
callback to return (the old 'devm' Completion). Here, both sides only
wait for drop_in_place() to finish, which completes within the current
call chain. The Arc> keeps the Inner allocation alive
independently.

Cc: stable@vger.kernel.org
Fixes: ba268514ea14 ("rust: devres: fix race condition due to nesting")
Reviewed-by: Gary Guo 
Reviewed-by: Alice Ryhl 
Link: https://patch.msgid.link/20260628200304.2365598-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich 
Signed-off-by: Greg Kroah-Hartman

rust: devres: fix race between concurrent revokers

2026-09-07T15:36:31+00:00

commit acc516dfa1972d31836b50abc0115216cd0fccc5 upstream.

There is a potential race condition when two paths try to revoke a
Devres concurrently.

The driver core's devres_release_all() calls Revocable::revoke() via the
release callback, while Devres::drop() calls revoke_nosync() on another
CPU.

The revoker that does not claim the is_available swap returns
immediately, but the revoker that did may still be executing
drop_in_place() on the inner data. This can cause a use-after-free when
the other revoker's caller proceeds to drop adjacent resources that
drop_in_place() still references (e.g., Devres racing with
SGTable freeing the backing sg_table and pages).

Fix this by adding a Completion. The release callback signals the
Completion after revoke() finishes, and Devres::drop() waits for it when
it loses the is_available swap. This ensures the wrapped object is fully
torn down before Devres::drop() returns.

Cc: stable@vger.kernel.org
Reported-by: Sashiko 
Closes: https://lore.kernel.org/dri-devel/20260612202841.2577C1F000E9@smtp.kernel.org/
Fixes: 05aa6fb1c21d ("rust: scatterlist: Add abstraction for sg_table")
Reviewed-by: Gary Guo 
Reviewed-by: Alice Ryhl 
Link: https://patch.msgid.link/20260628174451.2275679-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich 
Signed-off-by: Greg Kroah-Hartman

rust: dma: return zero for Coherent reads past EOF

2026-09-07T15:36:31+00:00

commit 5391b147d9fd8d4736e28c629cda00fd37c2304a upstream.

Coherent::write_to_slice() calculates a zero-byte copy when the file
offset is beyond the allocation, but still calls
UserSliceWriter::write_dma(). The latter rejects offsets beyond the
allocation even when the copy length is zero, so a debugfs read past EOF
returns -ERANGE.

Return before calling write_dma() when the offset is at or beyond the
allocation, matching simple_read_from_buffer() EOF semantics.

Fixes: 016818513936 ("rust: dma: implement BinaryWriter for Coherent<[u8]>")
Cc: stable@vger.kernel.org
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/291566-Library/topic/.E2.9C.94.20Possible.20past-EOF.20bug.20in.20Coherent.3CT.3E.3A.3Awrite_to_slice/near/611677095
Signed-off-by: Younes Akhouayri 
Reviewed-by: Alexandre Courbot 
Reviewed-by: Onur Özkan 
Link: https://patch.msgid.link/20260730-fix-dma-coherent-eof-v2-1-8aff21054afa@younes.io
Signed-off-by: Danilo Krummrich 
Signed-off-by: Greg Kroah-Hartman

rust: bug: prevent dead_code warning from warn_on!'s flags constant

2026-09-07T15:36:31+00:00

commit e66cfc29e0d06fec34c06bb40d4d281f595677b1 upstream.

Fix the following dead_code warning on some configurations in an
atomic development branch:

warning: constant `WARN_ON_FLAGS` is never used
   --> linux/rust/kernel/bug.rs:126:19
    |
126 |               const WARN_ON_FLAGS: u32 = $crate::bug::bugflag_taint($crate::bindings::TAINT_WARN);
    |                     ^^^^^^^^^^^^^
    |
   ::: linux/rust/kernel/sync/srcu.rs:106:12
    |
106 |           if crate::warn_on!(
    |  ____________-
107 | |             // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`
108 | |             // and `srcu_readers_active()` only checks the active reader count.
109 | |             unsafe { bindings::srcu_readers_active(ptr) }
110 | |         ) {
    | |_________- in this macro invocation
    |
    = note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default
    = note: this warning originates in the macro `crate::warn_on` (in Nightly builds, run with -Z macro-backtrace for more info)

The warn_on! macro always defines a WARN_ON_FLAGS constant and hands it
to warn_flags!. On configurations where warn_flags! does not reference
its flags argument (the LOONGARCH/ARM variant, which only calls
WARN_ON(), and the !CONFIG_BUG no-op variant), the constant is left
unused and triggers a dead_code warning.

warn_flags! is the macro that accepts (and here discards) the flags
argument, so make it responsible for the argument it drops.

Also rename `_COND_STR` to `COND_STR` and consume `$file` for consistency.

Fixes: dff64b072708 ("rust: Add warn_on macro")
Signed-off-by: FUJITA Tomonori 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260801024841.786664-1-tomo@flapping.org
[ Added newlines. - Miguel ]
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman