On Fri, Oct 18, 2024 at 4:48 PM Roberto Sassu roberto.sassu@huaweicloud.com 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: stable@vger.kernel.org Fixes: ea7e2d5e49c0 ("mm: call the security_mmap_file() LSM hook in remap_file_pages()") Reported-by: syzbot+91ae49e1c1a2634d20c0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-security-module/66f7b10e.050a0220.46d20.0036.G... Reviewed-by: Roberto Sassu roberto.sassu@huawei.com (Calculate prot and flags earlier) Signed-off-by: Kirill A. Shutemov kirill.shutemov@linux.intel.com
Reviewed-by: Jann Horn jannh@google.com