Hi Mimi, On Fri, Jul 12, 2019 at 04:41:37PM -0400, Mimi Zohar wrote: > The LSM security_mmap_file hook is called before the mmap_sem is taken. > This results in IMA taking the i_mutex before the mmap_sem, yet the > normal locking order is mmap_sem, i_mutex. > > To resolve this problem, rename and call ima_mmap_file() after taking > the mmap_sem. > I don't think this is correct. The normal order is i_mutex, then mmap_sem. E.g., for buffered writes i_mutex is taken, then when each page is written the page may have to be faulted into memory which takes mmap_sem. What seems to have happened is that due to your patch "ima: verify mprotect change is consistent with mmap policy" which was in linux-next for a while, syzbot found a reproducer on next-20190531 for "possible deadlock in process_measurement" (https://lkml.kernel.org/lkml/00000000000054e5d1058a6df2eb@xxxxxxxxxx/), which already had an open syzbot report for some other reason, possibly overlayfs-related. The same mprotect issue also got reported in 2 other syzbot reports, "possible deadlock in get_user_pages_unlocked (2)" and "possible deadlock in __do_page_fault (2)". Since your patch was dropped from linux-next, the issue no longer exists. I invalidated the other 2 reports for you but I didn't notice this one because it was a much older syzbot report. So I suggest just invalidating the report "possible deadlock in process_measurement" too, unless you think you think the older overlayfs-related deadlock report is still valid and actionable. It doesn't have a reproducer and was last seen 5 months ago, so it *might* be stale: https://syzkaller.appspot.com/text?tag=CrashReport&x=1767eeef400000 - Eric
