{"id":"DEBIAN-CVE-2026-23077","details":"In the Linux kernel, the following vulnerability has been resolved:  mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge  Patch series \"mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge\", v2.  Commit 879bca0a2c4f (\"mm/vma: fix incorrectly disallowed anonymous VMA merges\") introduced the ability to merge previously unavailable VMA merge scenarios.  However, it is handling merges incorrectly when it comes to mremap() of a faulted VMA adjacent to an unfaulted VMA.  The issues arise in three cases:  1. Previous VMA unfaulted:                copied -----|                           v \t|-----------|.............| \t| unfaulted |(faulted VMA)| \t|-----------|.............| \t     prev  2. Next VMA unfaulted:                copied -----|                           v \t            |.............|-----------| \t            |(faulted VMA)| unfaulted |                     |.............|-----------| \t\t                      next  3. Both adjacent VMAs unfaulted:                copied -----|                           v \t|-----------|.............|-----------| \t| unfaulted |(faulted VMA)| unfaulted | \t|-----------|.............|-----------| \t     prev                      next  This series fixes each of these cases, and introduces self tests to assert that the issues are corrected.  I also test a further case which was already handled, to assert that my changes continues to correctly handle it:  4. prev unfaulted, next faulted:                copied -----|                           v \t|-----------|.............|-----------| \t| unfaulted |(faulted VMA)|  faulted  | \t|-----------|.............|-----------| \t     prev                      next  This bug was discovered via a syzbot report, linked to in the first patch in the series, I confirmed that this series fixes the bug.  I also discovered that we are failing to check that the faulted VMA was not forked when merging a copied VMA in cases 1-3 above, an issue this series also addresses.  I also added self tests to assert that this is resolved (and confirmed that the tests failed prior to this).  I also cleaned up vma_expand() as part of this work, renamed vma_had_uncowed_parents() to vma_is_fork_child() as the previous name was unduly confusing, and simplified the comments around this function.   This patch (of 4):  Commit 879bca0a2c4f (\"mm/vma: fix incorrectly disallowed anonymous VMA merges\") introduced the ability to merge previously unavailable VMA merge scenarios.  The key piece of logic introduced was the ability to merge a faulted VMA immediately next to an unfaulted VMA, which relies upon dup_anon_vma() to correctly handle anon_vma state.  In the case of the merge of an existing VMA (that is changing properties of a VMA and then merging if those properties are shared by adjacent VMAs), dup_anon_vma() is invoked correctly.  However in the case of the merge of a new VMA, a corner case peculiar to mremap() was missed.  The issue is that vma_expand() only performs dup_anon_vma() if the target (the VMA that will ultimately become the merged VMA): is not the next VMA, i.e.  the one that appears after the range in which the new VMA is to be established.  A key insight here is that in all other cases other than mremap(), a new VMA merge either expands an existing VMA, meaning that the target VMA will be that VMA, or would have anon_vma be NULL.  Specifically:  * __mmap_region() - no anon_vma in place, initial mapping. * do_brk_flags() - expanding an existing VMA. * vma_merge_extend() - expanding an existing VMA. * relocate_vma_down() - no anon_vma in place, initial mapping.  In addition, we are in the unique situation of needing to duplicate anon_vma state from a VMA that is neither the previous or next VMA being merged with.  dup_anon_vma() deals exclusively with the target=unfaulted, src=faulted case.  This leaves four possibilities, in each case where the copied VMA is faulted:  1. Previous VMA unfaulted:                copied -----|                         ---truncated---","modified":"2026-08-27T23:05:36.735689890Z","published":"2026-02-04T17:16:18.443Z","upstream":["CVE-2026-23077"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2026-23077"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.18.8-1"}]}],"versions":["6.12.100-1","6.12.101-1","6.12.105-1","6.12.38-1","6.12.41-1","6.12.43-1","6.12.43-1~bpo12+1","6.12.48-1","6.12.57-1","6.12.57-1~bpo12+1","6.12.63-1","6.12.63-1~bpo12+1","6.12.69-1","6.12.69-1~bpo12+1","6.12.73-1","6.12.73-1~bpo12+1","6.12.74-1","6.12.74-2","6.12.74-2~bpo12+1","6.12.85-1","6.12.85-1~bpo12+1","6.12.86-1","6.12.86-1~bpo12+1","6.12.88-1","6.12.88-1~bpo12+1","6.12.90-1","6.12.90-1~bpo12+1","6.12.90-2","6.12.90-2~bpo12+1","6.12.94-1","6.12.94-1~bpo12+1","6.12.95-1","6.12.95-1~bpo12+1","6.12.96-1","6.13.10-1~exp1","6.13.11-1~exp1","6.13.2-1~exp1","6.13.3-1~exp1","6.13.4-1~exp1","6.13.5-1~exp1","6.13.6-1~exp1","6.13.7-1~exp1","6.13.8-1~exp1","6.13.9-1~exp1","6.13~rc6-1~exp1","6.13~rc7-1~exp1","6.14.3-1~exp1","6.14.5-1~exp1","6.14.6-1~exp1","6.15-1~exp1","6.15.1-1~exp1","6.15.2-1~exp1","6.15.3-1~exp1","6.15.4-1~exp1","6.15.5-1~exp1","6.15.6-1~exp1","6.15~rc7-1~exp1","6.16-1~exp1","6.16.1-1~exp1","6.16.10-1","6.16.11-1","6.16.12-1","6.16.12-1~bpo13+1","6.16.12-2","6.16.3-1","6.16.3-1~bpo13+1","6.16.5-1","6.16.6-1","6.16.7-1","6.16.8-1","6.16.9-1","6.16~rc7-1~exp1","6.17.10-1","6.17.11-1","6.17.12-1","6.17.13-1","6.17.13-1~bpo13+1","6.17.2-1~exp1","6.17.5-1~exp1","6.17.6-1","6.17.7-1","6.17.7-2","6.17.8-1","6.17.8-1~bpo13+1","6.17.9-1","6.18.1-1~exp1","6.18.2-1~exp1","6.18.3-1","6.18.5-1","6.18.5-1~bpo13+1","6.18~rc4-1~exp1","6.18~rc4-1~exp2","6.18~rc5-1~exp1","6.18~rc6-1~exp1","6.18~rc7-1~exp1"],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2026-23077.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"}]}