CVE-2026-64469: binder: fix UAF in binder_thread_release()

In the Linux kernel, the following vulnerability has been resolved:

binder: fix UAF in binderthreadrelease()

When a thread exits, binderthreadrelease() walks its transaction stack to clear the t->from and t->toproc 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->toproc, the t->toproc->innerlock will not be acquired.

This means that transaction accesses in binderthreadrelease() after t->toproc has been cleared might race with binderfreetransaction() and cause a use-after-free error as reported by KASAN:

================================================================== BUG: KASAN: slab-use-after-free in binderthreadrelease+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: binderthreadrelease+0x5d0/0x798 binderioctl+0x12c0/0x299c [...]

Allocated by task 717 on cpu 18 at 67.267803s: kasankmalloc+0xa0/0xbc kmalloccachenoprof+0x174/0x444 bindertransaction+0x554/0x8150 binderthreadwrite+0xa30/0x4354 binderioctl+0x20f0/0x299c [...]

Freed by task 202 on cpu 18 at 90.416221s: kasanslabfree+0x58/0x80 kfree+0x1a0/0x4a4 binderfreetransaction+0x150/0x294 bindersendfailedreply+0x398/0x6d8 binderreleasework+0x3e4/0x4ec binderdeferredfunc+0xbd8/0x104c [...] ==================================================================

In order to avoid this, make sure that binderfreetransaction() reads the t->toproc under the transaction lock. This will serialize the transaction release with the accesses in binderthreadrelease(). Plus, it matches the documented locking rules for @toproc.