possible deadlock in process_measurement

[Eric Biggers]

Hi Mimi,

On Thu, Jul 11, 2019 at 10:14:36AM -0400, Mimi Zohar wrote:
> Hi Eric,
> 
> On Mon, 2019-06-03 at 09:35 -0700, syzbot wrote:
> > syzbot has found a reproducer for the following crash on:
> > 
> > HEAD commit:    3c09c195 Add linux-next specific files for 20190531
> > git tree:       linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=10f61a0ea00000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=6cfb24468280cd5c
> > dashboard link: https://syzkaller.appspot.com/bug?extid=5ab61747675a87ea359d
> > compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=177c3d16a00000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14ec01baa00000
> > 
> 
> This reproducer seems like it is similar, but the cause is different
> than the original report.  One has to do with overlayfs, while the
> other has to do with ext4, mprotect/mmap.  I assume in both cases an
> IMA policy was required to trigger the locking bug.  What type of IMA
> policy are you using?
> 
> Do we need to differentiate the two reports?  Is the "last occurred"
> notification for the overlay, for mprotect, or both?  Please Cc the
> overlay mailing list on the overlay aspect.

AFAICS, syzbot boots all kernels with "ima_policy=tcb" on the command line.
And I don't think anything in userspace changes the IMA policy.

It's not unusual for multiple underlying bugs to get mixed into the same syzbot
bug.  syzbot doesn't know that one "possible deadlock in process_measurement" is
different from another.  "Last occurred" is for any crash that appeared as such.

This just needs to be handled the best we can.  Sometimes all the bugs can be
fixed; sometimes they've already been fixed; or sometimes it's easiest to fix
just one and then mark the syzbot bug as fixed, and syzbot will report it again
it's still occurring for some other reason.

- Eric