CVE-2026-64468

What it actually does

This is a local use-after-free vulnerability in the Linux kernel Binder driver. In binder_free_transaction(), the kernel reads a transaction's target process pointer while holding the transaction lock, then drops that lock before taking a lock on the target process. If the target process exits concurrently, that process object can be freed before the later lock operation, causing the kernel to access freed memory. Because the vulnerable code runs in kernel context and the CVSS vector indicates local, low-complexity exploitation with low privileges and no user interaction, a successful exploit could potentially lead to kernel memory corruption, privilege escalation, information disclosure, or denial of service.

Why it matters to the business

Systems running a vulnerable Linux kernel with Binder enabled may allow a local low-privileged user or compromised application to crash the system or potentially gain elevated privileges. The most likely business impact is loss of host or device stability, but the high confidentiality, integrity, and availability impact means successful exploitation could also undermine endpoint, mobile, embedded, or container-host trust boundaries where untrusted local code can interact with Binder. EPSS is currently low and the issue is not listed in CISA KEV, so broad active exploitation is not indicated, but the vulnerability is recent and kernel privilege-escalation issues can become more serious once exploit details mature.

How an attack unfolds

An attacker first needs the ability to run local code as an unprivileged user on a system where the Binder driver is available. The attacker then opens and interacts with the Binder device, creating Binder processes, threads, and transactions. By carefully racing transaction cleanup against target process or thread teardown, the attacker attempts to cause binder_free_transaction() to retain a stale reference to a process object that has already been freed. When the kernel later tries to acquire the freed object's lock, memory corruption occurs. A simple exploit path may only crash the kernel, while a more advanced exploit would attempt to shape heap allocations around the freed Binder process object so the stale pointer references attacker-influenced memory, potentially enabling kernel control-flow or data-only privilege escalation.

How to fix it

Upgrade to a kernel version or vendor kernel package that includes the Binder fix for this use-after-free condition. The upstream fix pins the target Binder thread so the target process remains alive while binder_free_transaction() uses it. No exact fixed package versions were provided in the input, so affected organizations should consult their Linux distribution, Android, embedded platform, or device vendor advisories for the first kernel build containing the fix for CVE-2026-64468. Where immediate patching is not possible, reduce exposure by disabling Binder if it is not required, restricting access to Binder device nodes through device permissions, SELinux/AppArmor policy, container device allowlists, or equivalent controls, and limiting the ability of untrusted local users or workloads to execute code on affected systems. Because this is a kernel memory-safety issue, configuration mitigations should be treated as temporary risk reduction rather than a substitute for patching.

How to confirm the fix worked

Confirm the running kernel is updated to a build that includes the Binder transaction lifetime fix. Validate using the vendor package changelog, kernel source commit history, or distribution security advisory for the running kernel branch. On systems where Binder is unnecessary, confirm Binder device nodes are absent or inaccessible to untrusted users, such as /dev/binder, /dev/hwbinder, /dev/vndbinder, or binderfs-mounted equivalents. Review kernel logs after testing or production operation for KASAN, BUG, oops, panic, or stack traces referencing binder_free_transaction(), binder_send_failed_reply(), binder_thread_release(), binder_ioctl(), binder_proc_dec_tmpref(), or binder_deferred_func(). If kernel self-tests or vendor regression tests are available for Binder IPC, run them after upgrading to ensure Binder remains functional and no UAF diagnostics are emitted.

Typical attack path

1. Gain local code execution as an unprivileged user or application on a system exposing the Binder driver.
2. Open the Binder device and create Binder IPC state, including processes, threads, and transactions.
3. Trigger failed or undelivered Binder transaction cleanup paths involving binder_free_transaction().
4. Race transaction cleanup with target process or thread exit so the target process object is freed after the transaction lock is released.
5. Cause the kernel to access the freed Binder process object when acquiring its inner lock.
6. Use the resulting memory corruption to crash the system or, with additional heap manipulation, attempt local privilege escalation.

How to detect it

Detection should focus on evidence of attempted Binder race exploitation and resulting kernel memory corruption. Useful sources include kernel ring buffer logs, persistent system journals, Android logcat/kernel logs, crash dump infrastructure, KASAN reports, panic/oops records, endpoint telemetry showing unusual local processes repeatedly opening Binder devices, and container runtime logs showing Binder device exposure. Look for crashes or warnings whose stack traces include binder_free_transaction(), binder_send_failed_reply(), binder_thread_release(), binder_ioctl(), binder_proc_dec_tmpref(), or binder_deferred_func(). Repeated Binder-related kernel faults, especially preceded by high-volume Binder device access from an untrusted application or user process, should be investigated. Because the vulnerability is a race condition in kernel memory management, there may be no clean application-level indicator if exploitation succeeds; absence of logs does not prove absence of exploitation, particularly if crash dumps or persistent kernel logging are disabled.

• BUG: KASAN: slab-use-after-free in _raw_spin_lock
• slab-use-after-free in _raw_spin_lock
• binder_free_transaction
• binder_send_failed_reply
• binder_thread_release
• binder_ioctl
• binder_proc_dec_tmpref
• binder_deferred_func
• /dev/binder
• /dev/hwbinder
• /dev/vndbinder
• binderfs
• KASAN: slab-use-after-free
• kernel BUG
• kernel oops

What your security team should do

• Prioritize patching systems that expose Binder to untrusted local applications, shared users, containers, mobile workloads, Android-derived environments, or embedded components.
• Inventory Linux and Android-derived kernels where Binder is enabled, including binderfs deployments and device nodes such as /dev/binder, /dev/hwbinder, and /dev/vndbinder.
• Use vendor advisories to identify the first fixed kernel package for each platform and schedule kernel updates with reboot windows as required.
• Until patching is complete, restrict Binder device access to only trusted services and remove Binder device passthrough from containers or sandboxes that do not require it.
• Increase monitoring for kernel crash, KASAN, oops, panic, and Binder-related stack traces, especially on systems that allow local users or untrusted application execution.
• Treat unexpected Binder-related kernel crashes as potentially security-relevant and preserve kernel logs, crash dumps, and process execution telemetry for investigation.
• Track exploit maturity because local kernel use-after-free vulnerabilities often become higher priority if proof-of-concept or weaponized exploit code is released.