CVE-2026-64469

What it actually does

This is a local use-after-free vulnerability in the Linux kernel Binder IPC subsystem. During thread teardown, binder_thread_release() walks a transaction stack while a parallel process-exit path may free one of the same binder_transaction objects through binder_free_transaction(). If locking does not consistently serialize access to the transaction's to_proc pointer, the kernel can write to memory after it has been freed. In practical terms, a local authenticated attacker able to interact with Binder could attempt to trigger a race condition that causes kernel memory corruption, potentially leading to kernel crash, denial of service, or privilege escalation to kernel-level execution depending on exploitability on a given kernel build, architecture, and hardening configuration.

Why it matters to the business

Systems using affected Linux kernel builds with Binder enabled may be exposed to local privilege escalation or system instability. The most relevant operational risk is on Android-derived systems, embedded devices, containers or hosts that expose Binder device nodes, and Linux distributions or custom kernels that include Binder support. Although the EPSS score is currently low, the CVSS rating is high because successful exploitation could allow a lower-privileged local user or compromised app/process to gain extensive control over the affected system. It is not listed in CISA KEV and there is no known ransomware association from the supplied data, so urgency should be driven by Binder exposure, multi-user risk, untrusted local code execution, and fleet criticality.

How an attack unfolds

An attacker first obtains the ability to run local code as an unprivileged user or application on a system where the Binder driver is present and accessible. They then open a Binder device and create Binder transactions between processes or threads. By carefully timing thread exit, process teardown, failed replies, and transaction cleanup, the attacker attempts to win a race between binder_thread_release() and binder_free_transaction(). If the race is won, the kernel accesses a freed binder_transaction object. A simple exploit may only crash the kernel, while a more advanced exploit would attempt to shape heap allocations so the freed memory is reused with attacker-controlled data, turning the use-after-free into a kernel memory corruption primitive and potentially escalating privileges.

How to fix it

Apply a kernel update that includes the upstream Binder fix for this issue. The fix changes transaction locking so binder_free_transaction() reads the transaction's to_proc field under the transaction lock, serializing release paths with binder_thread_release(). No exact affected product list or fixed package versions were provided, so remediation should be tracked through the relevant Linux distribution, Android device vendor, embedded vendor, or kernel maintainer advisories. Where immediate patching is not possible, reduce exposure by disabling Binder support if it is not required, removing or restricting access to Binder device nodes, limiting local shell/app execution by untrusted users, enforcing SELinux/AppArmor policies, and prioritizing updates for devices that run untrusted applications or support multiple users.

How to confirm the fix worked

Confirm the running kernel includes the vendor or upstream patch for the Binder use-after-free. Validate by checking the installed kernel package version against the vendor advisory or by confirming the source tree contains the locking change in binder_free_transaction() and related Binder transaction cleanup code. On live systems, verify whether Binder is present by checking for Binder device nodes and loaded/configured Binder support. After patching, reboot into the fixed kernel and confirm the active kernel version, not just the installed package version. For high-assurance validation, run vendor regression tests or Binder IPC stress tests in a non-production environment and confirm no KASAN, use-after-free, binder_thread_release(), or binder_free_transaction() warnings appear in kernel logs.

Typical attack path

1. Gain local code execution on a system with Binder enabled and accessible, typically as a low-privileged user or application.
2. Open a Binder device node such as a Binder IPC interface exposed by the platform.
3. Create Binder IPC transactions involving multiple threads or processes.
4. Force one thread to exit while a related process or transaction cleanup path runs in parallel.
5. Trigger the race between transaction-stack cleanup and transaction freeing.
6. Cause a use-after-free condition in kernel Binder code.
7. Use the resulting memory corruption to crash the system or, with a reliable exploit, attempt kernel privilege escalation.

How to detect it

Look for evidence of attempted exploitation or instability in kernel logs, crash dumps, Android log buffers, panic reports, and endpoint telemetry. Relevant sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl kernel logs, Android logcat kernel buffers, pstore/ramoops, crash dumps, and EDR telemetry for abnormal access to Binder device nodes. Search for KASAN or kernel BUG reports mentioning slab-use-after-free, binder_thread_release(), binder_free_transaction(), binder_send_failed_reply(), binder_release_work(), or binder_deferred_func(). Repeated kernel oops/panic events tied to Binder, especially after local processes rapidly open Binder devices and exit threads/processes, may indicate attempted triggering. Because exploitation is a race condition and no public exploit maturity was provided, absence of logs does not prove absence of exploitation; successful privilege escalation may leave only secondary signs such as unexpected root processes, SELinux denials followed by privilege changes, abnormal Binder device access, or unexplained device reboots.

• BUG: KASAN: slab-use-after-free in binder_thread_release
• slab-use-after-free in binder_thread_release
• binder_thread_release+
• binder_free_transaction+
• binder_send_failed_reply+
• binder_release_work+
• binder_deferred_func+
• binder_ioctl+
• Write of size 8 at addr
• /dev/binder
• /dev/vndbinder
• /dev/hwbinder
• KASAN: slab-use-after-free
• kernel BUG at drivers/android/binder
• drivers/android/binder.c

What your security team should do

• Inventory systems and device classes that run Linux kernels with Binder enabled, especially Android, embedded, mobile, automotive, and custom Linux platforms.
• Prioritize patching for systems where untrusted local users, applications, containers, or workloads can access Binder interfaces.
• Track vendor advisories for exact fixed kernel/package versions because no per-product fixed versions were supplied in the input.
• Where patching is delayed, restrict access to Binder device nodes and disable Binder support where it is not operationally required.
• Harden local execution boundaries with SELinux, AppArmor, least-privilege application confinement, and restrictions on interactive shell access.
• Monitor kernel logs for Binder-related crashes, KASAN reports, slab-use-after-free messages, and suspicious repeated process/thread teardown activity involving Binder.
• Treat unexplained Binder kernel crashes on exposed systems as potentially security-relevant until patched and investigated.
• Because this is not currently KEV-listed and EPSS is low, align urgency with local attack surface rather than internet exposure; systems running untrusted local code should still be handled with high priority.