CVE-2026-43434

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