CVE-2024-53096

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: resolve faulty mmap_region() error path behaviour<br /> <br /> The mmap_region() function is somewhat terrifying, with spaghetti-like<br /> control flow and numerous means by which issues can arise and incomplete<br /> state, memory leaks and other unpleasantness can occur.<br /> <br /> A large amount of the complexity arises from trying to handle errors late<br /> in the process of mapping a VMA, which forms the basis of recently<br /> observed issues with resource leaks and observable inconsistent state.<br /> <br /> Taking advantage of previous patches in this series we move a number of<br /> checks earlier in the code, simplifying things by moving the core of the<br /> logic into a static internal function __mmap_region().<br /> <br /> Doing this allows us to perform a number of checks up front before we do<br /> any real work, and allows us to unwind the writable unmap check<br /> unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE<br /> validation unconditionally also.<br /> <br /> We move a number of things here:<br /> <br /> 1. We preallocate memory for the iterator before we call the file-backed<br /> memory hook, allowing us to exit early and avoid having to perform<br /> complicated and error-prone close/free logic. We carefully free<br /> iterator state on both success and error paths.<br /> <br /> 2. The enclosing mmap_region() function handles the mapping_map_writable()<br /> logic early. Previously the logic had the mapping_map_writable() at the<br /> point of mapping a newly allocated file-backed VMA, and a matching<br /> mapping_unmap_writable() on success and error paths.<br /> <br /> We now do this unconditionally if this is a file-backed, shared writable<br /> mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however<br /> doing so does not invalidate the seal check we just performed, and we in<br /> any case always decrement the counter in the wrapper.<br /> <br /> We perform a debug assert to ensure a driver does not attempt to do the<br /> opposite.<br /> <br /> 3. We also move arch_validate_flags() up into the mmap_region()<br /> function. This is only relevant on arm64 and sparc64, and the check is<br /> only meaningful for SPARC with ADI enabled. We explicitly add a warning<br /> for this arch if a driver invalidates this check, though the code ought<br /> eventually to be fixed to eliminate the need for this.<br /> <br /> With all of these measures in place, we no longer need to explicitly close<br /> the VMA on error paths, as we place all checks which might fail prior to a<br /> call to any driver mmap hook.<br /> <br /> This eliminates an entire class of errors, makes the code easier to reason<br /> about and more robust.