{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-23077", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2026-01-13T15:37:45.959Z", "datePublished": "2026-02-04T16:08:02.274Z", "dateUpdated": "2026-02-09T08:38:16.924Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-02-09T08:38:16.924Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge\n\nPatch series \"mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted\nmerge\", v2.\n\nCommit 879bca0a2c4f (\"mm/vma: fix incorrectly disallowed anonymous VMA\nmerges\") introduced the ability to merge previously unavailable VMA merge\nscenarios.\n\nHowever, it is handling merges incorrectly when it comes to mremap() of a\nfaulted VMA adjacent to an unfaulted VMA. The issues arise in three\ncases:\n\n1. Previous VMA unfaulted:\n\n copied -----|\n v\n\t|-----------|.............|\n\t| unfaulted |(faulted VMA)|\n\t|-----------|.............|\n\t prev\n\n2. Next VMA unfaulted:\n\n copied -----|\n v\n\t |.............|-----------|\n\t |(faulted VMA)| unfaulted |\n |.............|-----------|\n\t\t next\n\n3. Both adjacent VMAs unfaulted:\n\n copied -----|\n v\n\t|-----------|.............|-----------|\n\t| unfaulted |(faulted VMA)| unfaulted |\n\t|-----------|.............|-----------|\n\t prev next\n\nThis series fixes each of these cases, and introduces self tests to assert\nthat the issues are corrected.\n\nI also test a further case which was already handled, to assert that my\nchanges continues to correctly handle it:\n\n4. prev unfaulted, next faulted:\n\n copied -----|\n v\n\t|-----------|.............|-----------|\n\t| unfaulted |(faulted VMA)| faulted |\n\t|-----------|.............|-----------|\n\t prev next\n\nThis bug was discovered via a syzbot report, linked to in the first patch\nin the series, I confirmed that this series fixes the bug.\n\nI also discovered that we are failing to check that the faulted VMA was\nnot forked when merging a copied VMA in cases 1-3 above, an issue this\nseries also addresses.\n\nI also added self tests to assert that this is resolved (and confirmed\nthat the tests failed prior to this).\n\nI also cleaned up vma_expand() as part of this work, renamed\nvma_had_uncowed_parents() to vma_is_fork_child() as the previous name was\nunduly confusing, and simplified the comments around this function.\n\n\nThis patch (of 4):\n\nCommit 879bca0a2c4f (\"mm/vma: fix incorrectly disallowed anonymous VMA\nmerges\") introduced the ability to merge previously unavailable VMA merge\nscenarios.\n\nThe key piece of logic introduced was the ability to merge a faulted VMA\nimmediately next to an unfaulted VMA, which relies upon dup_anon_vma() to\ncorrectly handle anon_vma state.\n\nIn the case of the merge of an existing VMA (that is changing properties\nof a VMA and then merging if those properties are shared by adjacent\nVMAs), dup_anon_vma() is invoked correctly.\n\nHowever in the case of the merge of a new VMA, a corner case peculiar to\nmremap() was missed.\n\nThe issue is that vma_expand() only performs dup_anon_vma() if the target\n(the VMA that will ultimately become the merged VMA): is not the next VMA,\ni.e. the one that appears after the range in which the new VMA is to be\nestablished.\n\nA key insight here is that in all other cases other than mremap(), a new\nVMA merge either expands an existing VMA, meaning that the target VMA will\nbe that VMA, or would have anon_vma be NULL.\n\nSpecifically:\n\n* __mmap_region() - no anon_vma in place, initial mapping.\n* do_brk_flags() - expanding an existing VMA.\n* vma_merge_extend() - expanding an existing VMA.\n* relocate_vma_down() - no anon_vma in place, initial mapping.\n\nIn addition, we are in the unique situation of needing to duplicate\nanon_vma state from a VMA that is neither the previous or next VMA being\nmerged with.\n\ndup_anon_vma() deals exclusively with the target=unfaulted, src=faulted\ncase. This leaves four possibilities, in each case where the copied VMA\nis faulted:\n\n1. Previous VMA unfaulted:\n\n copied -----|\n \n---truncated---"}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["mm/vma.c", "mm/vma.h"], "versions": [{"version": "879bca0a2c4f40b08d09a95a2a0c3c6513060b5c", "lessThan": "a4d9dbfc1bab16e25fefd34b5e537a46bed8fc96", "status": "affected", "versionType": "git"}, {"version": "879bca0a2c4f40b08d09a95a2a0c3c6513060b5c", "lessThan": "61f67c230a5e7c741c352349ea80147fbe65bfae", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["mm/vma.c", "mm/vma.h"], "versions": [{"version": "6.16", "status": "affected"}, {"version": "0", "lessThan": "6.16", "status": "unaffected", "versionType": "semver"}, {"version": "6.18.8", "lessThanOrEqual": "6.18.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.19", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "cpeApplicability": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.16", "versionEndExcluding": "6.18.8"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.16", "versionEndExcluding": "6.19"}]}]}], "references": [{"url": "https://git.kernel.org/stable/c/a4d9dbfc1bab16e25fefd34b5e537a46bed8fc96"}, {"url": "https://git.kernel.org/stable/c/61f67c230a5e7c741c352349ea80147fbe65bfae"}], "title": "mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge", "x_generator": {"engine": "bippy-1.2.0"}}}}

{}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "467E1359-7F6A-4790-AC45-172024944460", "versionEndExcluding": "6.18.8", "versionStartIncluding": "6.16", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc1:*:*:*:*:*:*", "matchCriteriaId": "17B67AA7-40D6-4AFA-8459-F200F3D7CFD1", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc2:*:*:*:*:*:*", "matchCriteriaId": "C47E4CC9-C826-4FA9-B014-7FE3D9B318B2", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc3:*:*:*:*:*:*", "matchCriteriaId": "F71D92C0-C023-48BD-B3B6-70B638EEE298", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc4:*:*:*:*:*:*", "matchCriteriaId": "13580667-0A98-40CC-B29F-D12790B91BDB", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc5:*:*:*:*:*:*", "matchCriteriaId": "CAD1FED7-CF48-47BF-AC7D-7B6FA3C065FC", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge\n\nPatch series \"mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted\nmerge\", v2.\n\nCommit 879bca0a2c4f (\"mm/vma: fix incorrectly disallowed anonymous VMA\nmerges\") introduced the ability to merge previously unavailable VMA merge\nscenarios.\n\nHowever, it is handling merges incorrectly when it comes to mremap() of a\nfaulted VMA adjacent to an unfaulted VMA. The issues arise in three\ncases:\n\n1. Previous VMA unfaulted:\n\n copied -----|\n v\n\t|-----------|.............|\n\t| unfaulted |(faulted VMA)|\n\t|-----------|.............|\n\t prev\n\n2. Next VMA unfaulted:\n\n copied -----|\n v\n\t |.............|-----------|\n\t |(faulted VMA)| unfaulted |\n |.............|-----------|\n\t\t next\n\n3. Both adjacent VMAs unfaulted:\n\n copied -----|\n v\n\t|-----------|.............|-----------|\n\t| unfaulted |(faulted VMA)| unfaulted |\n\t|-----------|.............|-----------|\n\t prev next\n\nThis series fixes each of these cases, and introduces self tests to assert\nthat the issues are corrected.\n\nI also test a further case which was already handled, to assert that my\nchanges continues to correctly handle it:\n\n4. prev unfaulted, next faulted:\n\n copied -----|\n v\n\t|-----------|.............|-----------|\n\t| unfaulted |(faulted VMA)| faulted |\n\t|-----------|.............|-----------|\n\t prev next\n\nThis bug was discovered via a syzbot report, linked to in the first patch\nin the series, I confirmed that this series fixes the bug.\n\nI also discovered that we are failing to check that the faulted VMA was\nnot forked when merging a copied VMA in cases 1-3 above, an issue this\nseries also addresses.\n\nI also added self tests to assert that this is resolved (and confirmed\nthat the tests failed prior to this).\n\nI also cleaned up vma_expand() as part of this work, renamed\nvma_had_uncowed_parents() to vma_is_fork_child() as the previous name was\nunduly confusing, and simplified the comments around this function.\n\n\nThis patch (of 4):\n\nCommit 879bca0a2c4f (\"mm/vma: fix incorrectly disallowed anonymous VMA\nmerges\") introduced the ability to merge previously unavailable VMA merge\nscenarios.\n\nThe key piece of logic introduced was the ability to merge a faulted VMA\nimmediately next to an unfaulted VMA, which relies upon dup_anon_vma() to\ncorrectly handle anon_vma state.\n\nIn the case of the merge of an existing VMA (that is changing properties\nof a VMA and then merging if those properties are shared by adjacent\nVMAs), dup_anon_vma() is invoked correctly.\n\nHowever in the case of the merge of a new VMA, a corner case peculiar to\nmremap() was missed.\n\nThe issue is that vma_expand() only performs dup_anon_vma() if the target\n(the VMA that will ultimately become the merged VMA): is not the next VMA,\ni.e. the one that appears after the range in which the new VMA is to be\nestablished.\n\nA key insight here is that in all other cases other than mremap(), a new\nVMA merge either expands an existing VMA, meaning that the target VMA will\nbe that VMA, or would have anon_vma be NULL.\n\nSpecifically:\n\n* __mmap_region() - no anon_vma in place, initial mapping.\n* do_brk_flags() - expanding an existing VMA.\n* vma_merge_extend() - expanding an existing VMA.\n* relocate_vma_down() - no anon_vma in place, initial mapping.\n\nIn addition, we are in the unique situation of needing to duplicate\nanon_vma state from a VMA that is neither the previous or next VMA being\nmerged with.\n\ndup_anon_vma() deals exclusively with the target=unfaulted, src=faulted\ncase. This leaves four possibilities, in each case where the copied VMA\nis faulted:\n\n1. Previous VMA unfaulted:\n\n copied -----|\n \n---truncated---"}, {"lang": "es", "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: mm/vma: corrige UAF de anon_vma en mremap() con fusi\u00f3n de VMA faulted y unfaulted Serie de parches \"mm/vma: corrige UAF de anon_vma en mremap() con fusi\u00f3n de VMA faulted y unfaulted\", v2. El commit 879bca0a2c4f ('mm/vma: corrige fusiones de VMA an\u00f3nimas incorrectamente denegadas') introdujo la capacidad de fusionar escenarios de fusi\u00f3n de VMA previamente no disponibles. Sin embargo, est\u00e1 manejando las fusiones incorrectamente cuando se trata de mremap() de un VMA faulted adyacente a un VMA unfaulted. Los problemas surgen en tres casos: 1. VMA anterior unfaulted:copiado -----| v .............| | unfaulted |(VMA faulted)| .............| anterior 2. Siguiente VMA unfaulted:copiado -----| v |(VMA faulted)| unfaulted | siguiente 3. Ambos VMA adyacentes unfaulted:copiado -----| v ............. | unfaulted |(VMA faulted)| unfaulted | ............. anterior siguiente Esta serie corrige cada uno de estos casos e introduce auto-pruebas para afirmar que los problemas est\u00e1n corregidos. Tambi\u00e9n pruebo un caso adicional que ya estaba manejado, para afirmar que mis cambios contin\u00faan manej\u00e1ndolo correctamente: 4. anterior unfaulted, siguiente faulted:copiado -----| v ............. | unfaulted |(VMA faulted)| faulted | ............. anterior siguiente Este error fue descubierto a trav\u00e9s de un informe de syzbot, enlazado en el primer parche de la serie, confirm\u00e9 que esta serie corrige el error. Tambi\u00e9n descubr\u00ed que no estamos verificando que el VMA faulted no fue bifurcado al fusionar un VMA copiado en los casos 1-3 anteriores, un problema que esta serie tambi\u00e9n aborda. Tambi\u00e9n agregu\u00e9 auto-pruebas para afirmar que esto est\u00e1 resuelto (y confirm\u00e9 que las pruebas fallaron antes de esto). Tambi\u00e9n limpi\u00e9 vma_expand() como parte de este trabajo, renombr\u00e9 vma_had_uncowed_parents() a vma_is_fork_child() ya que el nombre anterior era indebidamente confuso, y simplifiqu\u00e9 los comentarios alrededor de esta funci\u00f3n. Este parche (de 4): El commit 879bca0a2c4f ('mm/vma: corrige fusiones de VMA an\u00f3nimas incorrectamente denegadas') introdujo la capacidad de fusionar escenarios de fusi\u00f3n de VMA previamente no disponibles. La pieza clave de l\u00f3gica introducida fue la capacidad de fusionar un VMA faulted inmediatamente adyacente a un VMA unfaulted, lo cual se basa en dup_anon_vma() para manejar correctamente el estado de anon_vma. En el caso de la fusi\u00f3n de un VMA existente (es decir, cambiando propiedades de un VMA y luego fusionando si esas propiedades son compartidas por VMA adyacentes), dup_anon_vma() se invoca correctamente. Sin embargo, en el caso de la fusi\u00f3n de un nuevo VMA, se pas\u00f3 por alto un caso particular peculiar de mremap(). El problema es que vma_expand() solo realiza dup_anon_vma() si el objetivo (el VMA que finalmente se convertir\u00e1 en el VMA fusionado): no es el siguiente VMA, es decir, el que aparece despu\u00e9s del rango en el que se establecer\u00e1 el nuevo VMA. Una idea clave aqu\u00ed es que en todos los dem\u00e1s casos, aparte de mremap(), una nueva fusi\u00f3n de VMA o bien expande un VMA existente, lo que significa que el VMA objetivo ser\u00e1 ese VMA, o anon_vma ser\u00eda NULL. Espec\u00edficamente: * __mmap_region() - no hay anon_vma en su lugar, mapeo inicial. * do_brk_flags() - expandiendo un VMA existente. * vma_merge_extend() - expandiendo un VMA existente. * relocate_vma_down() - no hay anon_vma en su lugar, mapeo inicial. Adem\u00e1s, nos encontramos en la situaci\u00f3n \u00fanica de necesitar duplicar el estado de anon_vma de un VMA que no es ni el VMA anterior ni el siguiente con el que se est\u00e1 fusionando. dup_anon_vma() se ocupa exclusivamente del caso objetivo=unfaulted, fuente=faulted. Esto deja cuatro posibilidades, en cada caso donde el VMA copiado es faulted: 1. VMA anterior unfaulted:copiado -----| ---truncado---"}], "id": "CVE-2026-23077", "lastModified": "2026-03-18T13:59:31.013", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 7.8, "baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 5.9, "source": "nvd@nist.gov", "type": "Primary"}]}, "published": "2026-02-04T17:16:18.443", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/61f67c230a5e7c741c352349ea80147fbe65bfae"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/a4d9dbfc1bab16e25fefd34b5e537a46bed8fc96"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-416"}], "source": "nvd@nist.gov", "type": "Primary"}]}

{"bugzilla": {"description": "kernel: mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge", "id": "2436795", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2436795"}, "csaw": false, "details": ["No description is available for this CVE."], "name": "CVE-2026-23077", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:10", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 10"}, {"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2026-02-04T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2026-23077\nhttps://nvd.nist.gov/vuln/detail/CVE-2026-23077\nhttps://lore.kernel.org/linux-cve-announce/2026020420-CVE-2026-23077-6880@gregkh/T"]}

{}