linux-kernel - Re: kernel panic with v5.18-rc1 on OpenPandora (only)

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: <CAK8P3a3N9WBWC_ECB0pSRHUCT4iz=tdT+Dt9Cyd5Wh3qEaVqqA@mail.gmail.com>
Date:   Wed, 27 Apr 2022 11:37:13 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Tony Lindgren <tony@...mide.com>
Cc:     "H. Nikolaus Schaller" <hns@...delico.com>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Ard Biesheuvel <ardb@...nel.org>, Arnd Bergmann <arnd@...db.de>
Subject: Re: kernel panic with v5.18-rc1 on OpenPandora (only)

On Wed, Apr 27, 2022 at 10:38 AM Tony Lindgren <tony@...mide.com> wrote:
> * H. Nikolaus Schaller <hns@...delico.com> [220426 20:16]:
> > [   28.245727] [<c0100b60>] (__irq_svc) from [<c0905de0>] (_raw_spin_unlock_irq+0x20/0x4c)
> > [   28.254150] [<c0905de0>] (_raw_spin_unlock_irq) from [<c0902e94>] (do_wait_for_common+0xa8/0x138)
> > [   28.263488] [<c0902e94>] (do_wait_for_common) from [<c0902f54>] (wait_for_common+0x30/0x48)
> > [   28.272277] [<c0902f54>] (wait_for_common) from [<c074edf8>] (mmc_wait_for_req_done+0x1c/0x90)
> > [   28.281341] [<c074edf8>] (mmc_wait_for_req_done) from [<c075a72c>] (mmc_io_rw_extended+0x1c0/0x2f4)
> > [   28.290893] [<c075a72c>] (mmc_io_rw_extended) from [<c075bd00>] (sdio_io_rw_ext_helper+0x118/0x140)
> > [   28.300415] [<c075bd00>] (sdio_io_rw_ext_helper) from [<c075bdd0>] (sdio_memcpy_toio+0x18/0x20)
> > [   28.309570] [<c075bdd0>] (sdio_memcpy_toio) from [<bf3de1ec>] (wl1251_sdio_write+0x34/0x54 [wl1251_sdio])
> > [   28.319702] [<bf3de1ec>] (wl1251_sdio_write [wl1251_sdio]) from [<bf40fc8c>] (wl1251_set_partition+0x90/0x404 [wl1251])
> > [   28.331207] [<bf40fc8c>] (wl1251_set_partition [wl1251]) from [<bf4074ec>] (wl1251_init_ieee80211+0x1c0/0x3dc [wl1251])

I think the problem is here: wl1251_set_partition() passes a local
stack variable into
an SDIO API function that is given to the hardware. This was never
safe and could
cause a corrupted stack because of the cache management, but with vmap stacks
it turns into a reliable DMA error, which I guess is what the l3
interrupt is about.

Can you change wl1251_set_partition() to use kmalloc()/kfree() to allocate the
partitions[] array? You said that it still crashes without the wl1251
driver, so I assume
there is at least one more related bug. If you get a different call
chain without the
driver, or with the kmalloc() call, can you post that as well?

       Arnd