CVE-2026-43434

{"id": "CVE-2026-43434", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Secondary", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 7.8, "attackVector": "LOCAL", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "impactScore": 5.9, "exploitabilityScore": 1.8}]}, "affected": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "affectedData": [{"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "eafedbc7c050c44744fbdf80bdf3315e860b7513", "lessThan": "20a01f20d1f4064d90a8627aa41b5987f0220bb9", "versionType": "git"}, {"status": "affected", "version": "eafedbc7c050c44744fbdf80bdf3315e860b7513", "lessThan": "5a472d04fb4b9115fb7d1535bd885cea450f14db", "versionType": "git"}, {"status": "affected", "version": "eafedbc7c050c44744fbdf80bdf3315e860b7513", "lessThan": "8ef2c15aeae07647f530d30f6daaf79eb801bcd1", "versionType": "git"}], "programFiles": ["drivers/android/binder/page_range.rs"], "defaultStatus": "unaffected"}, {"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "6.18"}, {"status": "unaffected", "version": "0", "lessThan": "6.18", "versionType": "semver"}, {"status": "unaffected", "version": "6.18.19", "versionType": "semver", "lessThanOrEqual": "6.18.*"}, {"status": "unaffected", "version": "6.19.9", "versionType": "semver", "lessThanOrEqual": "6.19.*"}, {"status": "unaffected", "version": "7.0", "versionType": "original_commit_for_fix", "lessThanOrEqual": "*"}], "programFiles": ["drivers/android/binder/page_range.rs"], "defaultStatus": "affected"}]}], "published": "2026-05-08T15:16:55.713", "references": [{"url": "https://git.kernel.org/stable/c/20a01f20d1f4064d90a8627aa41b5987f0220bb9", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/5a472d04fb4b9115fb7d1535bd885cea450f14db", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/8ef2c15aeae07647f530d30f6daaf79eb801bcd1", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "NVD-CWE-noinfo"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nrust_binder: check ownership before using vma\n\nWhen installing missing pages (or zapping them), Rust Binder will look\nup the vma in the mm by address, and then call vm_insert_page (or\nzap_page_range_single). However, if the vma is closed and replaced with\na different vma at the same address, this can lead to Rust Binder\ninstalling pages into the wrong vma.\n\nBy installing the page into a writable vma, it becomes possible to write\nto your own binder pages, which are normally read-only. Although you're\nnot supposed to be able to write to those pages, the intent behind the\ndesign of Rust Binder is that even if you get that ability, it should not\nlead to anything bad. Unfortunately, due to another bug, that is not the\ncase.\n\nTo fix this, store a pointer in vm_private_data and check that the vma\nreturned by vma_lookup() has the right vm_ops and vm_private_data before\ntrying to use the vma. This should ensure that Rust Binder will refuse\nto interact with any other VMA. The plan is to introduce more vma\nabstractions to avoid this unsafe access to vm_ops and vm_private_data,\nbut for now let's start with the simplest possible fix.\n\nC Binder performs the same check in a slightly different way: it\nprovides a vm_ops->close that sets a boolean to true, then checks that\nboolean after calling vma_lookup(), but this is more fragile\nthan the solution in this patch. (We probably still want to do both, but\nthe vm_ops->close callback will be added later as part of the follow-up\nvma API changes.)\n\nIt's still possible to remap the vma so that pages appear in the right\nvma, but at the wrong offset, but this is a separate issue and will be\nfixed when Rust Binder gets a vm_ops->close callback."}, {"lang": "es", "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nrust_binder: comprobar la propiedad antes de usar vma\n\nAl instalar p\u00e1ginas faltantes (o eliminarlas), Rust Binder buscar\u00e1 el vma en el mm por direcci\u00f3n, y luego llamar\u00e1 a vm_insert_page (o zap_page_range_single). Sin embargo, si el vma se cierra y se reemplaza con un vma diferente en la misma direcci\u00f3n, esto puede llevar a que Rust Binder instale p\u00e1ginas en el vma incorrecto.\n\nAl instalar la p\u00e1gina en un vma escribible, se hace posible escribir en sus propias p\u00e1ginas de binder, que normalmente son de solo lectura. Aunque no se supone que se pueda escribir en esas p\u00e1ginas, la intenci\u00f3n detr\u00e1s del dise\u00f1o de Rust Binder es que incluso si se obtiene esa capacidad, no deber\u00eda conducir a nada malo. Desafortunadamente, debido a otro error, ese no es el caso.\n\nPara solucionar esto, almacene un puntero en vm_private_data y compruebe que el vma devuelto por vma_lookup() tiene los vm_ops y vm_private_data correctos antes de intentar usar el vma. Esto deber\u00eda asegurar que Rust Binder se negar\u00e1 a interactuar con cualquier otro VMA. El plan es introducir m\u00e1s abstracciones de vma para evitar este acceso inseguro a vm_ops y vm_private_data, pero por ahora, comencemos con la soluci\u00f3n m\u00e1s simple posible.\n\nC Binder realiza la misma comprobaci\u00f3n de una manera ligeramente diferente: proporciona un vm_ops -> close que establece un booleano en verdadero, luego comprueba ese booleano despu\u00e9s de llamar a vma_lookup(), pero esto es m\u00e1s fr\u00e1gil que la soluci\u00f3n en este parche. (Probablemente todav\u00eda queramos hacer ambas cosas, pero la devoluci\u00f3n de llamada vm_ops -> close se a\u00f1adir\u00e1 m\u00e1s tarde como parte de los cambios posteriores de la API de vma).\n\nTodav\u00eda es posible reasignar el vma para que las p\u00e1ginas aparezcan en el vma correcto, pero con el desplazamiento incorrecto, pero este es un problema separado y se solucionar\u00e1 cuando Rust Binder obtenga una devoluci\u00f3n de llamada vm_ops -> close."}], "lastModified": "2026-11-11T20:10:00.273", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "4B3A7D3C-8D62-43DB-ADD2-83F0634E4C23", "versionEndExcluding": "6.18.19", "versionStartIncluding": "6.18"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "E825E7C3-FEAC-4FD3-8A81-78D7387948C9", "versionEndExcluding": "6.19.9", "versionStartIncluding": "6.19"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "F253B622-8837-4245-BCE5-A7BF8FC76A16"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "4AE85AD8-4641-4E7C-A2F4-305E2CD9EE64"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "F666C8D8-6538-46D4-B318-87610DE64C34"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}