CVE-2026-43434
Received Received - Intake
Memory Corruption in Linux Kernel Rust Binder

Publication date: 2026-05-08

Last updated on: 2026-05-08

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-08
Last Modified
2026-05-08
Generated
2026-05-09
AI Q&A
2026-05-08
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Currently, no data is known.
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's Rust Binder component. When Rust Binder installs missing pages or removes them, it looks up a virtual memory area (vma) by address. However, if the original vma has been closed and replaced by a different one at the same address, Rust Binder might mistakenly install pages into the wrong vma.

Because of this, it becomes possible to write to binder pages that are normally read-only. Although the design intended that even if writing was possible it would not cause harm, another bug makes this unsafe.

The fix involves storing a pointer in vm_private_data and verifying that the vma returned by vma_lookup() has the correct vm_ops and vm_private_data before using it. This prevents Rust Binder from interacting with incorrect vmas.


How can this vulnerability impact me? :

This vulnerability can allow a user to write to binder pages that should be read-only. This unintended write access could potentially lead to unexpected behavior or security issues within the system, as the Rust Binder component may interact with incorrect memory areas.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability has been resolved in the Linux kernel by adding checks on the ownership of the virtual memory area (vma) before using it in Rust Binder. To mitigate this vulnerability immediately, you should update your Linux kernel to a version that includes this fix.

The fix involves storing a pointer in vm_private_data and verifying that the vma returned by vma_lookup() has the correct vm_ops and vm_private_data before usage, preventing Rust Binder from interacting with incorrect vmas.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart