<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-next.git/drivers/android, branch master</title>
<subtitle>Linux kernel latest source</subtitle>
<id>http://mirrors.hust.edu.cn/git/linux-next.git/atom?h=master</id>
<link rel='self' href='http://mirrors.hust.edu.cn/git/linux-next.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/'/>
<updated>2026-07-03T11:54:10+00:00</updated>
<entry>
<title>rust_binder: clear freeze listener on node removal</title>
<updated>2026-07-03T11:54:10+00:00</updated>
<author>
<name>Alice Ryhl</name>
<email>aliceryhl@google.com</email>
</author>
<published>2026-07-03T11:25:12+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=bc4a9828897871ff3e5a1f8a1d346decbf4ee95e'/>
<id>urn:sha1:bc4a9828897871ff3e5a1f8a1d346decbf4ee95e</id>
<content type='text'>
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 &lt;stable@kernel.org&gt;
Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver")
Signed-off-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Link: https://patch.msgid.link/20260703-remove-freeze-on-remove-node-v3-1-6e0c4547af46@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>rust_binder: reject context manager self-transaction</title>
<updated>2026-07-03T10:28:43+00:00</updated>
<author>
<name>Keshav Verma</name>
<email>iganschel@gmail.com</email>
</author>
<published>2026-06-25T10:39:57+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=6849cabfd30fb5727cfd31e8241e15801e17ebf9'/>
<id>urn:sha1:6849cabfd30fb5727cfd31e8241e15801e17ebf9</id>
<content type='text'>
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 &lt;stable@kernel.org&gt;
Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver")
Signed-off-by: Keshav Verma &lt;iganschel@gmail.com&gt;
Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Link: https://patch.msgid.link/20260625103957.730-1-iganschel@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>rust_binder: use a u64 stride when cleaning up the offsets array</title>
<updated>2026-07-03T10:28:28+00:00</updated>
<author>
<name>Hyunwoo Kim</name>
<email>imv4bel@gmail.com</email>
</author>
<published>2026-05-31T13:29:24+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=803c8a9502e9b97cd6ae937618ef4a8fd6274343'/>
<id>urn:sha1:803c8a9502e9b97cd6ae937618ef4a8fd6274343</id>
<content type='text'>
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 &lt;stable@kernel.org&gt;
Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver")
Signed-off-by: Hyunwoo Kim &lt;imv4bel@gmail.com&gt;
Acked-by: Carlos Llamas &lt;cmllamas@google.com&gt;
Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Link: https://patch.msgid.link/ahw3tFhLz9bMMJAO@v4bel
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>binder: fix UAF in binder_free_transaction()</title>
<updated>2026-07-03T10:28:12+00:00</updated>
<author>
<name>Carlos Llamas</name>
<email>cmllamas@google.com</email>
</author>
<published>2026-06-19T18:52:31+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=f223d27a546c1e1f48d38fd67760e78f068fe8c4'/>
<id>urn:sha1:f223d27a546c1e1f48d38fd67760e78f068fe8c4</id>
<content type='text'>
In binder_free_transaction(), the t-&gt;to_proc is read under the t-&gt;lock.
However, once the t-&gt;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-&gt;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 &lt;stable@kernel.org&gt;
Reported-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Closes: https://lore.kernel.org/all/aikJKVuny_eOivwN@google.com/
Fixes: a370003cc301 ("binder: fix possible UAF when freeing buffer")
Signed-off-by: Carlos Llamas &lt;cmllamas@google.com&gt;
Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Link: https://patch.msgid.link/20260619185233.2194678-2-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>binder: fix UAF in binder_thread_release()</title>
<updated>2026-07-03T10:28:08+00:00</updated>
<author>
<name>Carlos Llamas</name>
<email>cmllamas@google.com</email>
</author>
<published>2026-06-19T18:52:30+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=114a116aaa5f0295376cdf12da743c5bce3b20ce'/>
<id>urn:sha1:114a116aaa5f0295376cdf12da743c5bce3b20ce</id>
<content type='text'>
When a thread exits, binder_thread_release() walks its transaction stack
to clear the t-&gt;from and t-&gt;to_proc that correspond with the exiting
thread. However, a process dying in parallel might attempt to kfree some
of these transactions. And if one of them has no associated t-&gt;to_proc,
the t-&gt;to_proc-&gt;inner_lock will not be acquired.

This means that transaction accesses in binder_thread_release() after
t-&gt;to_proc has been cleared might race with binder_free_transaction()
and cause a use-after-free error as reported by KASAN:

  ==================================================================
  BUG: KASAN: slab-use-after-free in binder_thread_release+0x5d0/0x798
  Write of size 8 at addr ffff000016627500 by task X/715

  CPU: 17 UID: 0 PID: 715 Comm: X Not tainted 7.1.0-rc5-00149-g8fde5d1d47f6 #30 PREEMPT
  Hardware name: linux,dummy-virt (DT)
  Call trace:
   binder_thread_release+0x5d0/0x798
   binder_ioctl+0x12c0/0x299c
   [...]

  Allocated by task 717 on cpu 18 at 67.267803s:
   __kasan_kmalloc+0xa0/0xbc
   __kmalloc_cache_noprof+0x174/0x444
   binder_transaction+0x554/0x8150
   binder_thread_write+0xa30/0x4354
   binder_ioctl+0x20f0/0x299c
   [...]

  Freed by task 202 on cpu 18 at 90.416221s:
   __kasan_slab_free+0x58/0x80
   kfree+0x1a0/0x4a4
   binder_free_transaction+0x150/0x294
   binder_send_failed_reply+0x398/0x6d8
   binder_release_work+0x3e4/0x4ec
   binder_deferred_func+0xbd8/0x104c
   [...]
  ==================================================================

In order to avoid this, make sure that binder_free_transaction() reads
the t-&gt;to_proc under the transaction lock. This will serialize the
transaction release with the accesses in binder_thread_release(). Plus,
it matches the documented locking rules for @to_proc.

Cc: stable &lt;stable@kernel.org&gt;
Fixes: 7a4408c6bd3e ("binder: make sure accesses to proc/thread are safe")
Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Signed-off-by: Carlos Llamas &lt;cmllamas@google.com&gt;
Link: https://patch.msgid.link/20260619185233.2194678-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>rust_binder: synchronize Rust Binder stats with freeze commands</title>
<updated>2026-07-03T10:27:38+00:00</updated>
<author>
<name>Keshav Verma</name>
<email>iganschel@gmail.com</email>
</author>
<published>2026-06-15T21:17:43+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=eb1645bf10190e71f6f0316e37ff70755d719b53'/>
<id>urn:sha1:eb1645bf10190e71f6f0316e37ff70755d719b53</id>
<content type='text'>
Rust Binder stats use BC_COUNT and BR_COUNT to size the command and
return counters, and use event string tables when printing debug
statistics.

The Binder protocol includes freeze-related commands and return codes,
but the Rust Binder statistics code was not updated to cover them. As a
result, those commands and return codes are not accounted for or printed
by the stats debug output.

Update the counts and event string tables so these commands and return
codes are included in the debug statistics output.

Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver")
Cc: stable &lt;stable@kernel.org&gt;
Acked-by: Carlos Llamas &lt;cmllamas@google.com&gt;
Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Signed-off-by: Keshav Verma &lt;iganschel@gmail.com&gt;
Link: https://patch.msgid.link/20260615211743.734-1-iganschel@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>binder: cache secctx size before release zeroes it</title>
<updated>2026-07-03T10:26:32+00:00</updated>
<author>
<name>Chris Mason</name>
<email>clm@meta.com</email>
</author>
<published>2026-06-03T17:44:54+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=b34826e55aad3520ec813f1f367c11b24b29dc9f'/>
<id>urn:sha1:b34826e55aad3520ec813f1f367c11b24b29dc9f</id>
<content type='text'>
binder_transaction() bounds the scatter-gather buffer area with
sg_buf_end_offset and subtracts the aligned LSM context size because
the secctx is written at the tail of that area.  The subtraction reads
lsmctx.len, but that field has already been cleared by the time the
line runs:

    security_secid_to_secctx(secid, &amp;lsmctx)   /* lsmctx.len set */
    lsmctx_aligned_size = ALIGN(lsmctx.len, sizeof(u64))
    extra_buffers_size += lsmctx_aligned_size
    ...
    security_release_secctx(&amp;lsmctx)            /* memset zeroes len */
    ...
    sg_buf_end_offset = sg_buf_offset + extra_buffers_size
                        - ALIGN(lsmctx.len, sizeof(u64)) /* ALIGN(0,8) */

security_release_secctx() does memset(cp, 0, sizeof(*cp)), so lsmctx.len
reads back as 0 and the subtraction contributes nothing, leaving
sg_buf_end_offset too large by the aligned secctx size on every
transaction to a txn_security_ctx node.

Each BINDER_TYPE_PTR object then derives buf_left = sg_buf_end_offset -
sg_buf_offset as the sole upper bound on its copy, so the inflated end
offset lets the copy run into the bytes that already hold the secctx.

The aligned size must therefore be cached before release rather than
re-read from the now-cleared field.  Fix by caching it in
lsmctx_aligned_size at function scope when it is first computed and
subtracting lsmctx_aligned_size instead of re-reading lsmctx.len after
release.  Reuse the same value for the earlier buf_offset computation.

Fixes: 6fba89813ccf ("lsm: ensure the correct LSM context releaser")
Cc: stable &lt;stable@kernel.org&gt;
Assisted-by: kres:claude-opus-4-8
Signed-off-by: Chris Mason &lt;clm@meta.com&gt;
Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Acked-by: Carlos Llamas &lt;cmllamas@google.com&gt;
Link: https://patch.msgid.link/20260603174506.1957278-1-clm@meta.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>rust_binder: fix BINDER_GET_EXTENDED_ERROR</title>
<updated>2026-07-03T10:18:59+00:00</updated>
<author>
<name>Alice Ryhl</name>
<email>aliceryhl@google.com</email>
</author>
<published>2026-06-05T11:13:50+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=77bfebf110773f5a0d6b5ff8110896adb2c9c335'/>
<id>urn:sha1:77bfebf110773f5a0d6b5ff8110896adb2c9c335</id>
<content type='text'>
This code currently copies the ExtendedError struct to the stack,
modifies the copy, and then doesn't modify the original. Thus, fix it.

Furthermore, errors when replying must be delivered directly to the
remote thread, so update deliver_reply() to take an extended error
argument.

Cc: stable &lt;stable@kernel.org&gt;
Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver")
Signed-off-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Acked-by: Carlos Llamas &lt;cmllamas@google.com&gt;
Link: https://patch.msgid.link/20260605-set-extended-error-v3-1-d60b69a75f97@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'v7.1-rc6' into char-misc-next</title>
<updated>2026-06-01T16:10:34+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2026-06-01T16:10:34+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=da61573f783897ae5a96c8f1c71aad6242344feb'/>
<id>urn:sha1:da61573f783897ae5a96c8f1c71aad6242344feb</id>
<content type='text'>
We need the char/misc/iio fixes in here as well.

Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>binder: Use LIST_HEAD() to initialize on stack list head</title>
<updated>2026-05-23T11:47:32+00:00</updated>
<author>
<name>Jisheng Zhang</name>
<email>jszhang@kernel.org</email>
</author>
<published>2026-05-19T05:56:23+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=91f818b184b44b105b1c92859ea8d2d6f47912a9'/>
<id>urn:sha1:91f818b184b44b105b1c92859ea8d2d6f47912a9</id>
<content type='text'>
Use LIST_HEAD to initialize on stack list head. No intentional
functional impact.

Change generated with below coccinelle script:

@@
identifier name;
@@
- struct list_head name;
+ LIST_HEAD(name);
... when != name
- INIT_LIST_HEAD(&amp;name);

Signed-off-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Link: https://patch.msgid.link/20260519055623.13142-1-jszhang@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
