CVE-2026-64467

rust_binder: use a u64 stride when cleaning up the offsets array

Published Jul 25, 2026 CVSS 3.1 · 8.8 High EPSS < 1% KEV · Not listed
Description
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!

Remediation

No solution or workaround provided in the CVE record

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Ubuntu USN Ubuntu USN USN-8726-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8727-1 Linux kernel (OEM) vulnerabilities
Ubuntu USN Ubuntu USN USN-8728-1 Linux kernel (GCP) vulnerabilities
Ubuntu USN Ubuntu USN USN-8760-1 Linux kernel (NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-8726-2 Linux kernel (Raspberry Pi) vulnerabilities
Ubuntu USN Ubuntu USN USN-8726-3 Linux kernel (IBM) vulnerabilities
Ubuntu USN Ubuntu USN USN-8800-1 Linux kernel (NVIDIA BaseOS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8760-2 Linux kernel (NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-8726-4 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8728-2 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8728-3 Linux kernel (Oracle) vulnerabilities
History
Type Values Removed Values Added
Weaknesses CWE-191
CPEs cpe:2.3:o:linux:linux_kernel:7.2:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.2:rc2:*:*:*:*:*:*
Type Values Removed Values Added
Weaknesses CWE-399
Type Values Removed Values Added
Metrics cvssV3_1

{'score': 8.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H'}

Type Values Removed Values Added
Description 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!
Title rust_binder: use a u64 stride when cleaning up the offsets array
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References
Weaknesses

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Aug 17, 2026, 4:56 AM
Reserved
Jul 19, 2026, 3:36 PM
Status
Analyzed
Published
Jul 25, 2026, 10:17 AM
Modified
Nov 12, 2026, 6:01 PM
Severity
Public date
Jul 25, 2026, 12:00 AM