[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHC9VhQA3HxM9M0mf=-pWLcN9hVJXYuBstDV6xkU2FB1oAs3LQ@mail.gmail.com>
Date: Wed, 2 Oct 2024 22:52:34 -0400
From: Paul Moore <paul@...l-moore.com>
To: syzbot <syzbot+a6456f6334aa19425886@...kaller.appspotmail.com>
Cc: akpm@...ux-foundation.org, ebpqwerty472123@...il.com, hughd@...gle.com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
stephen.smalley.work@...il.com, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [mm?] possible deadlock in upgrade_mmap_lock_carefully
On Wed, Oct 2, 2024 at 9:32 PM syzbot
<syzbot+a6456f6334aa19425886@...kaller.appspotmail.com> wrote:
> > On Wed, Oct 2, 2024 at 8:14 AM Shu Han <ebpqwerty472123@...il.com> wrote:
> >>
> >> It seems to be the same as [1].
> >> New LSM hook position for remap_file_pages + IMA = deadlock.
> >> The new LSM hook position is added for a bypass caused by
> >> no check in remap_file_pages + READ_IMPLIES_EXEC in do_mmap.
> >
> > Thanks Shu Han, let's mark this as a dup and sort out a fix in the first report.
> >
> > #syz dup: [syzbot] [integrity?] [lsm?] possible deadlock in
>
> can't find the dup bug
>
> > process_measurement (4)
Stupid line wrapping, let's try again ...
#syz dup: possible deadlock in process_measurement (4)
> >> I suggest fix it by removing the check and moving READ_IMPLIES_EXEC
> >> out of do_mmap[2].
> >>
> >> Link: https://lore.kernel.org/lkml/20240928065620.7abadb2d8552f03d785c77c9@linux-foundation.org/
> >> [1]
> >> Link: https://lore.kernel.org/all/20240928180044.50-1-ebpqwerty472123@gmail.com/
> >> [2]
--
paul-moore.com
Powered by blists - more mailing lists