CVE-2026-53373

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vma: do not try to unmap a VMA if mmap_prepare() invoked from mmap()<br /> <br /> The mmap_prepare hook functionality includes the ability to invoke<br /> mmap_prepare() from the mmap() hook of existing &amp;#39;stacked&amp;#39; drivers, that is<br /> ones which are capable of calling the mmap hooks of other drivers/file<br /> systems (e.g. overlayfs, shm).<br /> <br /> As part of the mmap_prepare action functionality, we deal with errors by<br /> unmapping the VMA should one arise. This works in the usual mmap_prepare<br /> case, as we invoke this action at the last moment, when the VMA is<br /> established in the maple tree.<br /> <br /> However, the mmap() hook passes a not-fully-established VMA pointer to the<br /> caller (which is the motivation behind the mmap_prepare() work), which is<br /> detached.<br /> <br /> So attempting to unmap a VMA in this state will be problematic, with the<br /> most obvious symptom being a warning in vma_mark_detached(), because the<br /> VMA is already detached.<br /> <br /> It&amp;#39;s also unncessary - the mmap() handler will clean up the VMA on error.<br /> <br /> So to fix this issue, this patch propagates whether or not an mmap action<br /> is being completed via the compatibility layer or directly.<br /> <br /> If the former, then we do not attempt VMA cleanup, if the latter, then we<br /> do.<br /> <br /> This patch also updates the userland VMA tests to reflect the change.