kernel/git/next/linux-next.git/drivers/android, branch master

Merge branch 'char-misc-next' of https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git

2026-07-06T13:54:21+00:00

rust_binder: clear freeze listener on node removal

2026-07-03T11:54:10+00:00

Generally userspace is supposed to explicitly clear freeze listeners before they drop the refcount on the node ref to zero, but there's nothing forcing that. Currently, in this scenario the freeze listener remains in the freeze_listeners rbtree and in the remote node's freeze listener list, even though the ref for which the listener is registered is gone. This could potentially lead to a memory leak due to a refcount cycle. Thus, remove the freeze listener in this scenario. Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260703-remove-freeze-on-remove-node-v3-1-6e0c4547af46@google.com Signed-off-by: Greg Kroah-Hartman

rust: binder: enable `clippy::cast_lossless`

2026-07-03T10:29:38+00:00

Before Rust 1.29.0, Clippy introduced the `cast_lossless` lint [1]: > Rust's `as` keyword will perform many kinds of conversions, including > silently lossy conversions. Conversion functions such as `i32::from` > will only perform lossless conversions. Using the conversion functions > prevents conversions from becoming silently lossy if the input types > ever change, and makes it clear for people reading the code that the > conversion is lossless. While this does not eliminate unchecked `as` conversions, it makes such conversions easier to scrutinize. It also has the slight benefit of removing a degree of freedom on which to bikeshed. Thus apply the changes and enable the lint in the Binder Rust driver -- no functional change intended. Link: https://rust-lang.github.io/rust-clippy/master/index.html#cast_lossless [1] Reviewed-by: Alice Ryhl Assisted-by: Codex:gpt-5 Signed-off-by: Tamir Duberstein Link: https://patch.msgid.link/20260526-binder-strict-provenance-v2-5-a41d89c29bc5@kernel.org Signed-off-by: Greg Kroah-Hartman

rust: binder: enable `clippy::as_underscore`

2026-07-03T10:29:38+00:00

In Rust 1.63.0, Clippy introduced the `as_underscore` lint [1]: > The conversion might include lossy conversion or a dangerous cast that > might go undetected due to the type being inferred. > > The lint is allowed by default as using `_` is less wordy than always > specifying the type. Always specifying the type is especially helpful in function call contexts where the inferred type may change at a distance. Specifying the type also allows Clippy to spot more cases of `useless_conversion`. Several inferred conversions from `binder_uintptr_t` to the driver's internal `u64` node identifiers are identity conversions. Although the UAPI header retains `BINDER_IPC_32BIT` for userspace building against older kernels, commit 1190b4e38f97 ("ANDROID: binder: remove 32-bit binder interface.") removed kernel support for selecting that protocol. Rust Binder therefore uses the 64-bit Binder protocol on every supported architecture. While this does not eliminate unchecked `as` conversions, it makes such conversions easier to scrutinize. It also has the slight benefit of removing a degree of freedom on which to bikeshed. Thus apply the changes and enable the lint in the Binder Rust driver -- no functional change intended. Link: https://rust-lang.github.io/rust-clippy/master/index.html#as_underscore [1] Assisted-by: Codex:gpt-5 Signed-off-by: Tamir Duberstein Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260526-binder-strict-provenance-v2-4-a41d89c29bc5@kernel.org Signed-off-by: Greg Kroah-Hartman

rust: binder: enable `clippy::ref_as_ptr` lint

2026-07-03T10:29:38+00:00

In Rust 1.78.0, Clippy introduced the `ref_as_ptr` lint [1]: > Using `as` casts may result in silently changing mutability or type. While this does not eliminate unchecked `as` conversions, it makes such conversions easier to scrutinize. It also has the slight benefit of removing a degree of freedom on which to bikeshed. Thus apply the changes and enable the lint in the Binder Rust driver -- no functional change intended. Link: https://rust-lang.github.io/rust-clippy/master/index.html#ref_as_ptr [1] Assisted-by: Codex:gpt-5 Signed-off-by: Tamir Duberstein Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260526-binder-strict-provenance-v2-3-a41d89c29bc5@kernel.org Signed-off-by: Greg Kroah-Hartman

rust: binder: enable `clippy::ptr_as_ptr` lint

2026-07-03T10:29:38+00:00

In Rust 1.51.0, Clippy introduced the `ptr_as_ptr` lint [1]: > Though `as` casts between raw pointers are not terrible, > `pointer::cast` is safer because it cannot accidentally change pointer > mutability or cast the pointer to other types like `usize`. Apply the required changes and enable the lint in the Binder Rust driver -- no functional change intended. Link: https://rust-lang.github.io/rust-clippy/master/index.html#ptr_as_ptr [1] Assisted-by: Codex:gpt-5 Signed-off-by: Tamir Duberstein Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260526-binder-strict-provenance-v2-2-a41d89c29bc5@kernel.org Signed-off-by: Greg Kroah-Hartman

rust: binder: use strict provenance APIs

2026-07-03T10:29:38+00:00

Replace the pointer-to-integer conversions in the Binder Rust driver with calls to the strict provenance APIs. The strict provenance APIs were stabilized in Rust 1.84.0 [1]. Since commit f32fb9c58a5b ("rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)"), the minimum supported Rust version is 1.85.0, so no polyfills are needed. Link: https://blog.rust-lang.org/2025/01/09/Rust-1.84.0.html#strict-provenance-apis [1] Reviewed-by: Alice Ryhl Assisted-by: Codex:gpt-5 Signed-off-by: Tamir Duberstein Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260526-binder-strict-provenance-v2-1-a41d89c29bc5@kernel.org Signed-off-by: Greg Kroah-Hartman

rust_binder: reject context manager self-transaction

2026-07-03T10:28:43+00:00

Rust binder resolved handle 0 to the context manager node, but it does not reject the case where the caller owns the same node. The C binder driver rejects transactions from the context-manager process to handle 0 after resolving the target node. Match that behavior in Rust Binder by rejecting handle 0 transactions when the resolved context-manager node is owned by the calling process. This applies to both synchronous and oneway transactions because both paths resolve the target through Process::get_transaction_node(). Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Signed-off-by: Keshav Verma Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260625103957.730-1-iganschel@gmail.com Signed-off-by: Greg Kroah-Hartman

rust_binder: use a u64 stride when cleaning up the offsets array

2026-07-03T10:28:28+00:00

Allocation's Drop walks the offsets array (binder_size_t = u64 entries), cleaning up the objects, but it used usize instead of u64 for both the stride and the per-entry read. On 64-bit kernels (usize == u64) this is harmless, but on 32-bit kernels it walks the 8-byte entries in 4-byte steps, iterating an N-entry array 2N times, and reads the always-zero high word as offset 0, cleaning up the object at offset 0 N extra times. As a result the referenced node or handle ends up with a lower reference count than it actually has (a refcount over-decrement), and binder's reference accounting is corrupted; for example, the owner can be notified of a strong reference release (BR_RELEASE) even though references still remain. Change the stride to u64, and read each entry as a u64, narrowing it to usize with try_into(). On 32-bit ARM, when this over-decrement would drive a count below zero, the driver's existing refcount guard refuses it and fires: rust_binder: Failure: refcount underflow! Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Signed-off-by: Hyunwoo Kim Acked-by: Carlos Llamas Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/ahw3tFhLz9bMMJAO@v4bel Signed-off-by: Greg Kroah-Hartman

binder: fix UAF in binder_free_transaction()

2026-07-03T10:28:12+00:00

In binder_free_transaction(), the t->to_proc is read under the t->lock. However, once the t->lock is dropped, the to_proc can die in parallel. This leads to a use-after-free error when we attempt to acquire its inner lock right afterwards: ================================================================== BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x1a0 Write of size 4 at addr ffff00001125da70 by task B/672 CPU: 20 UID: 0 PID: 672 Comm: B Not tainted 7.1.0-rc6-00284-g8e65320d91cd #4 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: _raw_spin_lock+0xe4/0x1a0 binder_free_transaction+0x8c/0x320 binder_send_failed_reply+0x21c/0x2f8 binder_thread_release+0x488/0x7e0 binder_ioctl+0x12c0/0x29a0 [...] Allocated by task 675: __kmalloc_cache_noprof+0x174/0x444 binder_open+0x118/0xb70 do_dentry_open+0x374/0x1040 vfs_open+0x58/0x3bc [...] Freed by task 212: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_proc_dec_tmpref+0x32c/0x5e0 binder_deferred_func+0xc48/0x104c process_one_work+0x53c/0xbc0 [...] ================================================================== To prevent this, pin the target thread (t->to_thread) to guarantee the target process remains alive. Undelivered transactions without a target thread are already safe, as the target process can only be the current context in those paths. Cc: stable Reported-by: Alice Ryhl Closes: https://lore.kernel.org/all/aikJKVuny_eOivwN@google.com/ Fixes: a370003cc301 ("binder: fix possible UAF when freeing buffer") Signed-off-by: Carlos Llamas Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260619185233.2194678-2-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman