CVE-2026-64467

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: use a u64 stride when cleaning up the offsets array<br /> <br /> Allocation&amp;#39;s Drop walks the offsets array (binder_size_t = u64 entries),<br /> cleaning up the objects, but it used usize instead of u64 for both the<br /> stride and the per-entry read.<br /> <br /> On 64-bit kernels (usize == u64) this is harmless, but on 32-bit kernels<br /> it walks the 8-byte entries in 4-byte steps, iterating an N-entry array<br /> 2N times, and reads the always-zero high word as offset 0, cleaning up<br /> the object at offset 0 N extra times. As a result the referenced node or<br /> handle ends up with a lower reference count than it actually has (a<br /> refcount over-decrement), and binder&amp;#39;s reference accounting is corrupted;<br /> for example, the owner can be notified of a strong reference release<br /> (BR_RELEASE) even though references still remain.<br /> <br /> Change the stride to u64, and read each entry as a u64, narrowing it to<br /> usize with try_into().<br /> <br /> On 32-bit ARM, when this over-decrement would drive a count below zero,<br /> the driver&amp;#39;s existing refcount guard refuses it and fires:<br /> <br /> rust_binder: Failure: refcount underflow!