On Fri, Oct 18, 2024 at 4:48 PM Roberto Sassu <[email protected]> wrote: > Commit ea7e2d5e49c0 ("mm: call the security_mmap_file() LSM hook in > remap_file_pages()") fixed a security issue, it added an LSM check when > trying to remap file pages, so that LSMs have the opportunity to evaluate > such action like for other memory operations such as mmap() and mprotect(). > > However, that commit called security_mmap_file() inside the mmap_lock lock, > while the other calls do it before taking the lock, after commit > 8b3ec6814c83 ("take security_mmap_file() outside of ->mmap_sem"). > > This caused lock inversion issue with IMA which was taking the mmap_lock > and i_mutex lock in the opposite way when the remap_file_pages() system > call was called. > > Solve the issue by splitting the critical region in remap_file_pages() in > two regions: the first takes a read lock of mmap_lock and retrieves the VMA > and the file associated, and calculate the 'prot' and 'flags' variable; the > second takes a write lock on mmap_lock, checks that the VMA flags and the > VMA file descriptor are the same as the ones obtained in the first critical > region (otherwise the system call fails), and calls do_mmap(). > > In between, after releasing the read lock and taking the write lock, call > security_mmap_file(), and solve the lock inversion issue. > > Cc: [email protected] > Fixes: ea7e2d5e49c0 ("mm: call the security_mmap_file() LSM hook in > remap_file_pages()") > Reported-by: [email protected] > Closes: > https://lore.kernel.org/linux-security-module/[email protected]/ > Reviewed-by: Roberto Sassu <[email protected]> (Calculate prot and > flags earlier) > Signed-off-by: Kirill A. Shutemov <[email protected]>
Reviewed-by: Jann Horn <[email protected]>
