Re: [RFC PATCH] ima: fix ima_file_mmap circular locking dependency

[Eric Biggers <ebiggers@kernel.org>]

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@google.com/),
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