CVE-2024-53096丨mm：解决错误的 mmap_region() 错误路径行为

在Linux内核中，已经解决了一个漏洞，具体描述如下：关于mmap_region()函数的问题已经被解决，该函数的行为有些令人困惑，控制流程像意大利面一样复杂，存在许多可能出现问题的途径，以及不完整的状态、内存泄漏和其他不愉快的情况。大量的复杂性来自于试图在映射虚拟内存区域（VMA）的后期处理过程中处理错误，这也是最近观察到的资源泄漏和可观察的不一致状态问题的基础。我们利用此系列补丁的优势，将一些检查提前到代码中，通过将逻辑核心转移到静态内部函数__mmap_region()来简化事情。这样做可以让我们在进行任何实际工作之前执行一些前期检查，并且允许我们无条件地解开可写的取消映射检查，以及无条件地进行CONFIG_DEBUG_VM_MAPLE_TREE验证。我们在这里进行了一些改动：1. 在调用基于文件的内存挂钩之前，我们预先为迭代器分配内存，这样可以在早期退出，避免执行复杂且容易出错的关闭/释放逻辑。我们在成功和错误路径上都小心地释放了迭代器的状态。2. 外部的mmap_region()函数早期处理了mapping_map_writable()逻辑。以前，这个逻辑是在映射新分配的基于文件的VMA时进行的，成功和错误路径上都有相应的mapping_unmap_writable()。现在，如果这是一个基于文件、共享可写的映射，我们会无条件地进行此操作。如果驱动程序改变了标志以消除VM_MAYWRITE，然而这样做并不会使刚刚执行的密封检查无效，而且在任何情况下我们都会减少包装器中的计数器。我们执行一个调试断言以确保驱动程序不会尝试做相反的事情。3. 我们还将arch_validate_flags()移到了mmap_region()函数中。这仅与arm64和sparc64相关，并且这个检查只对启用了ADI的SPARC有意义。如果驱动程序使这个检查无效，我们会为这个架构明确添加一个警告，尽管代码最终应该被修复以消除对这个检查的需要。有了所有这些措施，我们不再需要在错误路径上显式关闭VMA，因为我们把所有可能失败的检查都放在了调用任何驱动程序mmap钩子之前。这消除了一类错误，使代码更容易理解和更稳健。