From: Kalle Valo <kvalo@codeaurora.org>
To: Lyude Paul <lyude@redhat.com>
Cc: brcm80211-dev-list@cypress.com,
Hante Meuleman <hante.meuleman@broadcom.com>,
Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>,
Franky Lin <franky.lin@broadcom.com>,
Arend van Spriel <arend.vanspriel@broadcom.com>,
Himanshu Jha <himanshujha199640@gmail.com>,
Dan Haab <dhaab@luxul.com>,
Jia-Shyr Chuang <saint.chuang@cypress.com>,
Ian Molton <ian@mnementh.co.uk>,
stable@vger.kernel.org, Chi-Hsien Lin <chi-hsien.lin@cypress.com>,
Wright Feng <wright.feng@cypress.com>,
"David S. Miller" <davem@davemloft.net>,
linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] brcmfmac: Fix out of bounds memory access during fw load
Date: Thu, 29 Nov 2018 15:33:28 +0000 (UTC) [thread overview]
Message-ID: <20181129153328.B0C1C606DC@smtp.codeaurora.org> (raw)
In-Reply-To: <20181124225707.12262-1-lyude@redhat.com>
Lyude Paul <lyude@redhat.com> wrote:
> I ended up tracking down some rather nasty issues with f2fs (and other
> filesystem modules) constantly crashing on my kernel down to a
> combination of out of bounds memory accesses, one of which was coming
> from brcmfmac during module load:
>
> [ 30.891382] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
> [ 30.894437] ==================================================================
> [ 30.901581] BUG: KASAN: global-out-of-bounds in brcmf_fw_alloc_request+0x42c/0x480 [brcmfmac]
> [ 30.909935] Read of size 1 at addr ffff2000024865df by task kworker/6:2/387
> [ 30.916805]
> [ 30.918261] CPU: 6 PID: 387 Comm: kworker/6:2 Tainted: G O 4.20.0-rc3Lyude-Test+ #19
> [ 30.927251] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
> [ 30.935964] Workqueue: events brcmf_driver_register [brcmfmac]
> [ 30.941641] Call trace:
> [ 30.944058] dump_backtrace+0x0/0x3e8
> [ 30.947676] show_stack+0x14/0x20
> [ 30.950968] dump_stack+0x130/0x1c4
> [ 30.954406] print_address_description+0x60/0x25c
> [ 30.959066] kasan_report+0x1b4/0x368
> [ 30.962683] __asan_report_load1_noabort+0x18/0x20
> [ 30.967547] brcmf_fw_alloc_request+0x42c/0x480 [brcmfmac]
> [ 30.967639] brcmf_sdio_probe+0x163c/0x2050 [brcmfmac]
> [ 30.978035] brcmf_ops_sdio_probe+0x598/0xa08 [brcmfmac]
> [ 30.983254] sdio_bus_probe+0x190/0x398
> [ 30.983270] really_probe+0x2a0/0xa70
> [ 30.983296] driver_probe_device+0x1b4/0x2d8
> [ 30.994901] __driver_attach+0x200/0x280
> [ 30.994914] bus_for_each_dev+0x10c/0x1a8
> [ 30.994925] driver_attach+0x38/0x50
> [ 30.994935] bus_add_driver+0x330/0x608
> [ 30.994953] driver_register+0x140/0x388
> [ 31.013965] sdio_register_driver+0x74/0xa0
> [ 31.014076] brcmf_sdio_register+0x14/0x60 [brcmfmac]
> [ 31.023177] brcmf_driver_register+0xc/0x18 [brcmfmac]
> [ 31.023209] process_one_work+0x654/0x1080
> [ 31.032266] worker_thread+0x4f0/0x1308
> [ 31.032286] kthread+0x2a8/0x320
> [ 31.039254] ret_from_fork+0x10/0x1c
> [ 31.039269]
> [ 31.044226] The buggy address belongs to the variable:
> [ 31.044351] brcmf_firmware_path+0x11f/0xfffffffffffd3b40 [brcmfmac]
> [ 31.055601]
> [ 31.057031] Memory state around the buggy address:
> [ 31.061800] ffff200002486480: 04 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
> [ 31.068983] ffff200002486500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 31.068993] >ffff200002486580: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
> [ 31.068999] ^
> [ 31.069017] ffff200002486600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 31.096521] ffff200002486680: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa
> [ 31.096528] ==================================================================
> [ 31.096533] Disabling lock debugging due to kernel taint
>
> It appears that when trying to determine the length of the string in the
> alternate firmware path, we make the mistake of not handling the case
> where the firmware path is empty correctly. Since strlen(mp_path) can
> return 0, we'll end up accessing mp_path[-1] when the firmware_path
> isn't provided through the module arguments.
>
> So, fix this by just setting the end char to '\0' by default, and only
> changing it if we have a non-zero length. Additionally, use strnlen()
> with BRCMF_FW_ALTPATH_LEN instead of strlen() just to be extra safe.
>
> Fixes: 2baa3aaee27f ("brcmfmac: introduce brcmf_fw_alloc_request() function")
> Cc: Hante Meuleman <hante.meuleman@broadcom.com>
> Cc: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
> Cc: Franky Lin <franky.lin@broadcom.com>
> Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: Arend Van Spriel <arend.vanspriel@broadcom.com>
> Cc: Himanshu Jha <himanshujha199640@gmail.com>
> Cc: Dan Haab <dhaab@luxul.com>
> Cc: Jia-Shyr Chuang <saint.chuang@cypress.com>
> Cc: Ian Molton <ian@mnementh.co.uk>
> Cc: <stable@vger.kernel.org> # v4.17+
> Signed-off-by: Lyude Paul <lyude@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
b72c51a58e6d brcmfmac: Fix out of bounds memory access during fw load
--
https://patchwork.kernel.org/patch/10696609/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
prev parent reply other threads:[~2018-11-29 15:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-24 22:57 [PATCH] brcmfmac: Fix out of bounds memory access during fw load Lyude Paul
2018-11-25 8:15 ` Kalle Valo
2018-11-29 15:33 ` Kalle Valo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181129153328.B0C1C606DC@smtp.codeaurora.org \
--to=kvalo@codeaurora.org \
--cc=arend.vanspriel@broadcom.com \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=brcm80211-dev-list@cypress.com \
--cc=chi-hsien.lin@cypress.com \
--cc=davem@davemloft.net \
--cc=dhaab@luxul.com \
--cc=franky.lin@broadcom.com \
--cc=hante.meuleman@broadcom.com \
--cc=himanshujha199640@gmail.com \
--cc=ian@mnementh.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pieter-paul.giesberts@broadcom.com \
--cc=saint.chuang@cypress.com \
--cc=stable@vger.kernel.org \
--cc=wright.feng@cypress.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).