Description
In the Linux kernel, the following vulnerability has been resolved:

rust_binder: check ownership before using vma

When installing missing pages (or zapping them), Rust Binder will look
up the vma in the mm by address, and then call vm_insert_page (or
zap_page_range_single). However, if the vma is closed and replaced with
a different vma at the same address, this can lead to Rust Binder
installing pages into the wrong vma.

By installing the page into a writable vma, it becomes possible to write
to your own binder pages, which are normally read-only. Although you're
not supposed to be able to write to those pages, the intent behind the
design of Rust Binder is that even if you get that ability, it should not
lead to anything bad. Unfortunately, due to another bug, that is not the
case.

To fix this, store a pointer in vm_private_data and check that the vma
returned by vma_lookup() has the right vm_ops and vm_private_data before
trying to use the vma. This should ensure that Rust Binder will refuse
to interact with any other VMA. The plan is to introduce more vma
abstractions to avoid this unsafe access to vm_ops and vm_private_data,
but for now let's start with the simplest possible fix.

C Binder performs the same check in a slightly different way: it
provides a vm_ops->close that sets a boolean to true, then checks that
boolean after calling vma_lookup(), but this is more fragile
than the solution in this patch. (We probably still want to do both, but
the vm_ops->close callback will be added later as part of the follow-up
vma API changes.)

It's still possible to remap the vma so that pages appear in the right
vma, but at the wrong offset, but this is a separate issue and will be
fixed when Rust Binder gets a vm_ops->close callback.
Published: 2026-05-08
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

A flaw in the Linux kernel’s Rust Binder subsystem allows an attacker to cause pages to be installed into a different virtual memory area when the original VMA is closed and a new one is mapped at the same address. This omission enables writing to pages that are normally read‑only, effectively giving an arbitrary kernel‑space write. Such a fault can be leveraged to modify critical kernel data structures and gain elevated privileges, making this a privilege‑escalation vulnerability.

Affected Systems

All kernel builds that include the unpatched Rust Binder implementation are affected. The CNA data lists only the Linux kernel as the product, and no specific version ranges are provided, so any Linux installation running a kernel prior to the patch is susceptible until the fix is applied or the kernel is updated.

Risk and Exploitability

Formal severity metrics are not available; the EPSS score is reported as less than 1%, indicating a low probability of exploitation in the wild. The vulnerability is not listed in the CISA KEV catalog, suggesting no documented active exploitation. Exploitation is likely local, requiring the attacker to be able to invoke a Binder operation from user space or to load a kernel module that triggers the vulnerable code path. Remote exploitation would require a prior foothold that grants code execution in the kernel context.

Generated by OpenCVE AI on May 9, 2026 at 15:56 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the kernel to a version that includes the Rust Binder fix or backport the patch from the upstream source.
  • If an immediate kernel upgrade is not feasible, disable or restrict Rust Binder by unloading the binder module or configuring the system to block binder services to user space.
  • Implement mandatory access controls such as SELinux or AppArmor to limit which processes can invoke Binder operations, thereby reducing the attack surface.

Generated by OpenCVE AI on May 9, 2026 at 15:56 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 09 May 2026 14:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-284

Sat, 09 May 2026 12:15:00 +0000


Fri, 08 May 2026 18:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-284

Fri, 08 May 2026 14:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: rust_binder: check ownership before using vma When installing missing pages (or zapping them), Rust Binder will look up the vma in the mm by address, and then call vm_insert_page (or zap_page_range_single). However, if the vma is closed and replaced with a different vma at the same address, this can lead to Rust Binder installing pages into the wrong vma. By installing the page into a writable vma, it becomes possible to write to your own binder pages, which are normally read-only. Although you're not supposed to be able to write to those pages, the intent behind the design of Rust Binder is that even if you get that ability, it should not lead to anything bad. Unfortunately, due to another bug, that is not the case. To fix this, store a pointer in vm_private_data and check that the vma returned by vma_lookup() has the right vm_ops and vm_private_data before trying to use the vma. This should ensure that Rust Binder will refuse to interact with any other VMA. The plan is to introduce more vma abstractions to avoid this unsafe access to vm_ops and vm_private_data, but for now let's start with the simplest possible fix. C Binder performs the same check in a slightly different way: it provides a vm_ops->close that sets a boolean to true, then checks that boolean after calling vma_lookup(), but this is more fragile than the solution in this patch. (We probably still want to do both, but the vm_ops->close callback will be added later as part of the follow-up vma API changes.) It's still possible to remap the vma so that pages appear in the right vma, but at the wrong offset, but this is a separate issue and will be fixed when Rust Binder gets a vm_ops->close callback.
Title rust_binder: check ownership before using vma
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-05-08T14:22:05.269Z

Reserved: 2026-05-01T14:12:56.009Z

Link: CVE-2026-43434

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-05-08T15:16:55.713

Modified: 2026-05-08T15:16:55.713

Link: CVE-2026-43434

cve-icon Redhat

Severity :

Publid Date: 2026-05-08T00:00:00Z

Links: CVE-2026-43434 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-09T16:00:13Z

Weaknesses