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!
Published: 2026-07-25
Score: 8.8 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability occurs in the rust_binder driver of the Linux kernel. The driver stores offsets as 64‑bit entries but uses a 32‑bit stride and per‑entry read when the drop logic walks the array. On 32‑bit kernels this causes the array to be traversed twice, leading to the reference count of some objects being decremented beyond its intended value. The result is reference count under‑decrement, which corrupts binder's reference accounting. This error is a resource‑management flaw classified as CWE‑399.

Affected Systems

The flaw applies to 32‑bit Linux kernel builds that include the original rust_binder implementation (e.g., ARM32 and other 32‑bit architectures where usize is 32 bits). It is not present on 64‑bit kernels because usize equals 64 bits. No specific kernel version range is listed, so any kernel prior to the patch that contains the stride bug is potentially vulnerable.

Risk and Exploitability

The CVSS score of 8.8 indicates high severity. The EPSS score of less than 1% shows a very low current exploitation probability, and the vulnerability is not listed in CISA's KEV catalog, indicating no known public exploitation. Based on the description, it is inferred that an attacker would need privileged or kernel‑level access to trigger the faulty cleanup, such as loading a malicious module or performing a local privilege‑escalation attack. The guard may indicate a panic condition, but that is inferred from the message. The impact could lead to incorrect reference accounting or a kernel panic, potentially causing a denial of service.

Generated by OpenCVE AI on August 2, 2026 at 12:31 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that incorporates the stride fix in rust_binder.
  • If updating the kernel is not immediately possible, rebuild the kernel with the rust_binder module disabled to avoid exercising the faulty drop logic.
  • Monitor kernel logs for "rust_binder: Failure: refcount underflow!" messages and investigate any associated crashes or stability issues.

Generated by OpenCVE AI on August 2, 2026 at 12:31 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 30 Jul 2026 03:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-399

Wed, 29 Jul 2026 12:15:00 +0000


Mon, 27 Jul 2026 05:15:00 +0000

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'}


Sat, 25 Jul 2026 09:30:00 +0000

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

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-05T12:42:20.472Z

Reserved: 2026-07-19T15:36:31.790Z

Link: CVE-2026-64467

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-07-25T10:17:32.003

Modified: 2026-07-27T05:16:52.793

Link: CVE-2026-64467

cve-icon Redhat

Severity :

Publid Date: 2026-07-25T00:00:00Z

Links: CVE-2026-64467 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-02T12:45:06Z

Weaknesses