CVE-2026-64467 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
rust_binder: use a u64 stride when cleaning up the offsets array
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!
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/25/2026
This vulnerability exists in the linux kernel's binder driver implementation where a critical flaw in memory management during object cleanup leads to corrupted reference counting. The issue specifically affects 32-bit kernel architectures where the data type mismatch creates a fundamental operational error in how the offsets array is processed during deallocation. The root cause lies in the use of usize for both stride calculation and per-entry reading operations when processing binder_size_t entries that are actually u64 values, creating a scenario where 8-byte entries are accessed in 4-byte increments.
The technical flaw manifests as an over-decrement of reference counts due to improper iteration logic. When the Drop implementation walks through the offsets array on 32-bit systems, it processes each 8-byte entry using 4-byte stride operations, effectively causing the cleanup process to iterate twice as many times as intended. This results in reading the upper 32 bits of each 64-bit value as if they were a separate 32-bit offset and performing cleanup operations on the same object multiple times. The vulnerability is categorized under CWE-129 as an insufficient bounds checking, specifically manifesting as improper input validation during memory management operations.
The operational impact of this vulnerability extends beyond simple reference counting errors to potentially compromise system stability and security integrity. When reference counts are incorrectly decremented, objects may be prematurely freed while still being referenced, leading to use-after-free conditions that could be exploited by malicious actors. The corruption affects the binder driver's ability to properly track object lifetimes, which is critical for inter-process communication mechanisms in android systems and kernel-based applications. This vulnerability directly impacts the ATT&CK technique T1068 under Privilege Escalation and T1499 under Endpoint Denial of Service due to its potential to cause system instability through improper resource management.
The fix implemented addresses this by changing the stride calculation from usize to u64 and ensuring that each entry is read as a u64 value before being narrowed to usize using try_into() conversion. This correction ensures proper iteration through the 64-bit entries on both 32-bit and 64-bit architectures while maintaining compatibility with existing code patterns. The solution specifically targets the ARM architecture where the refcount guard mechanism triggers when underflow conditions occur, providing an additional safety net against improper reference count manipulation. On 64-bit kernels the change is harmless since usize and u64 are equivalent, but on 32-bit systems it prevents the double iteration that causes the reference counting corruption.
The vulnerability demonstrates a classic case of architecture-specific programming errors where assumptions about data type sizes lead to subtle but critical operational failures. The issue highlights the importance of proper type handling in kernel code where memory management operations must be architecture-independent and maintain consistent behavior across different processor platforms. This particular flaw represents a fundamental breakdown in kernel memory management practices and underscores the necessity of careful attention to data alignment and type safety when implementing low-level system components that manage object lifetimes and reference counting mechanisms. The fix ensures that the binder driver maintains proper reference accounting regardless of the underlying architecture, preventing both immediate operational failures and potential exploitation vectors that could arise from improper resource management.