linux-kernel - Re: arm64 syzbot instances

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+aWtSRdq+P_pVXb2yXKzwiF9ECuy2B7yGW8dC-emRv5Fw@mail.gmail.com>
Date:   Fri, 12 Mar 2021 07:42:48 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Mark Rutland <mark.rutland@....com>, Marc Zyngier <maz@...nel.org>,
        Will Deacon <will@...nel.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        syzkaller <syzkaller@...glegroups.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: arm64 syzbot instances

On Thu, Mar 11, 2021 at 6:25 PM Dmitry Vyukov <dvyukov@...gle.com> wrote:
>
> On Thu, Mar 11, 2021 at 2:30 PM Arnd Bergmann <arnd@...db.de> wrote:
> >
> > On Thu, Mar 11, 2021 at 12:38 PM Dmitry Vyukov <dvyukov@...gle.com> wrote:
> > >
> > > The instances found few arm64-specific issues that we have not
> > > observed on other instances:
> >
> > I've had a brief look at these:
> >
> > > https://syzkaller.appspot.com/bug?id=1d22a2cc3521d5cf6b41bd6b825793c2015f861f
> >
> > This one  doesn't seem arm64 specific at all. While the KASAN report has shown
> > up on arm64, the link to
> > https://syzkaller.appspot.com/bug?id=aa8808729c0a3540e6a29f0d45394665caf79dca
> > seems to be for x86 machines running into the same problem.
>
> You are right. It's probably a consequence of some configs being enabled.
> I think we need to enable CONFIG_FW_LOADER_USER_HELPER on x86_64
> upstream instances as well.
>
>
> > Looking deeper into the log, I see that fw_load_sysfs_fallback() finds
> > an existing
> > list entry on the global "pending_fw_head" list, which seems to have been freed
> > earlier (the allocation listed here is not for a firmware load, so presumably it
> > was recycled in the meantime). The log shows that this is the second time that
> > loading the regulatory database failed in that run, so my guess is that it was
> > the first failed load that left the freed firmware private data on the
> > list, but I
> > don't see how that happened.
>
> Can it be as simple as: fw_load_sysfs_fallback adds fw to the pending
> list, but then returns with an error w/o removing it from the list?
> There are some errors checks after that:
> https://elixir.bootlin.com/linux/v5.12-rc2/source/drivers/base/firmware_loader/fallback.c#L536
> and it seems that the caller deletes fw in this case:
> https://elixir.bootlin.com/linux/v5.12-rc2/source/drivers/base/firmware_loader/main.c#L839

I've enabled CONFIG_FW_LOADER_USER_HELPER for all instances and syzbot
come up with a repro and KASAN report with alloc/free stacks:
https://lore.kernel.org/lkml/000000000000af467105bd5128fc@google.com/