CVE-2026-23184

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

binder: fix UAF in bindernetlinkreport()

Oneway transactions sent to frozen targets via binderproctransaction() return a BRTRANSACTIONPENDINGFROZEN error but they are still treated as successful since the target is expected to thaw at some point. It is then not safe to access 't' after BRTRANSACTIONPENDINGFROZEN errors as the transaction could have been consumed by the now thawed target.

This is the case for bindernetlinkreport() which derreferences 't' after a pending frozen error, as pointed out by the following KASAN report:

================================================================== BUG: KASAN: slab-use-after-free in bindernetlinkreport.isra.0+0x694/0x6c8 Read of size 8 at addr ffff00000f98ba38 by task binder-util/522

CPU: 4 UID: 0 PID: 522 Comm: binder-util Not tainted 6.19.0-rc6-00015-gc03e9c42ae8f #1 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: bindernetlinkreport.isra.0+0x694/0x6c8 bindertransaction+0x66e4/0x79b8 binderthreadwrite+0xab4/0x4440 binderioctl+0x1fd4/0x2940 [...]

Allocated by task 522: __kmalloccachenoprof+0x17c/0x50c bindertransaction+0x584/0x79b8 binderthreadwrite+0xab4/0x4440 binderioctl+0x1fd4/0x2940 [...]

Freed by task 488: kfree+0x1d0/0x420 binderfreetransaction+0x150/0x234 binderthreadread+0x2d08/0x3ce4 binder_ioctl+0x488/0x2940 [...] ==================================================================

Instead, make a transaction copy so the data can be safely accessed by bindernetlinkreport() after a pending frozen error. While here, add a comment about not using t->buffer in bindernetlinkreport().