Roberto Sassu
unread,Apr 14, 2026, 12:15:39 PMApr 14Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Paul Moore, Mimi Zohar, linux-...@vger.kernel.org, linux-secu...@vger.kernel.org, syzkall...@googlegroups.com, syzbot
> From: Paul Moore <
pa...@paul-moore.com>
> Sent: Tuesday, April 14, 2026 3:59 PM
> On Tue, Apr 14, 2026 at 2:48 AM syzbot
> <
syzbot+liste500...@syzkaller.appspotmail.com> wrote:
> >
> > Hello lsm maintainers/developers,
> >
> > This is a 31-day syzbot report for the lsm subsystem.
> > All related reports/information can be found at:
> >
https://syzkaller.appspot.com/upstream/s/lsm
> >
> > During the period, 0 new issues were detected and 0 were fixed.
> > In total, 3 issues are still open and 45 have already been fixed.
> >
> > Some of the still happening issues:
> >
> > Ref Crashes Repro Title
> > <1> 95 Yes INFO: task hung in process_measurement (3)
> >
>
https://syzkaller.appspot.com/bug?extid=cb9e66807bcb882cd0c5
> > <2> 68 Yes possible deadlock in keyring_clear (3)
> >
>
https://syzkaller.appspot.com/bug?extid=f55b043dacf43776b50c
> > <3> 31 Yes INFO: task hung in ima_file_free (4)
> >
> >
https://syzkaller.appspot.com/bug?extid=8036326eebe7d0140944
>
> Mimi, Roberto,
>
> If I recall correctly, we've discussed the process measurement issue before,
> and I thought it was being resolved. What is the current status on a fix?
>
> I don't recall discussing the ima_file_free() issue, but it looks like the syzbot
> reports go back to 2024; is there a fix under development for that?
I looked at some of the reports. My impression (can be wrong) is that the
syzbot report involves us also when a filesystem gets stuck.
For example, if you see:
https://syzkaller.appspot.com/text?tag=CrashReport&x=160ddb02580000
PID 6887 cannot progress because iint->mutex is likely held by PID 6895.
The last function I see in PID 6895 is io_schedule() which suggests me
that there is an I/O wait that could not be satisfied. PID 6888 cannot progress
as well because is waiting for jfs_get_block(), but PID 6895 is past that
(possibly holding the needed lock).
Sure, it is possible that there is a lock inversion that I missed, but I didn't
find it yet.
Roberto