We got the following use-after-free KASAN report:
BUG: KASAN: use-after-free in wiphy_resume+0x591/0x5a0 [cfg80211]
at addr
ffff8803fc244090
Read of size 8 by task kworker/u16:24/2587
CPU: 6 PID: 2587 Comm: kworker/u16:24 Tainted: G B 4.9.13-debug+
Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS 1.2.19 12/22/2016
Workqueue: events_unbound async_run_entry_fn
ffff880425d4f9d8 ffffffffaeedb541 ffff88042b80ef00 ffff8803fc244088
ffff880425d4fa00 ffffffffae84d7a1 ffff880425d4fa98 ffff8803fc244080
ffff88042b80ef00 ffff880425d4fa88 ffffffffae84da3a ffffffffc141f7d9
Call Trace:
[<
ffffffffaeedb541>] dump_stack+0x85/0xc4
[<
ffffffffae84d7a1>] kasan_object_err+0x21/0x70
[<
ffffffffae84da3a>] kasan_report_error+0x1fa/0x500
[<
ffffffffc141f7d9>] ? cfg80211_bss_age+0x39/0xc0 [cfg80211]
[<
ffffffffc141f83a>] ? cfg80211_bss_age+0x9a/0xc0 [cfg80211]
[<
ffffffffae48d46d>] ? trace_hardirqs_on+0xd/0x10
[<
ffffffffc13fb1c0>] ? wiphy_suspend+0xc70/0xc70 [cfg80211]
[<
ffffffffae84def1>] __asan_report_load8_noabort+0x61/0x70
[<
ffffffffc13fb100>] ? wiphy_suspend+0xbb0/0xc70 [cfg80211]
[<
ffffffffc13fb751>] ? wiphy_resume+0x591/0x5a0 [cfg80211]
[<
ffffffffc13fb751>] wiphy_resume+0x591/0x5a0 [cfg80211]
[<
ffffffffc13fb1c0>] ? wiphy_suspend+0xc70/0xc70 [cfg80211]
[<
ffffffffaf3b206e>] dpm_run_callback+0x6e/0x4f0
[<
ffffffffaf3b31b2>] device_resume+0x1c2/0x670
[<
ffffffffaf3b367d>] async_resume+0x1d/0x50
[<
ffffffffae3ee84e>] async_run_entry_fn+0xfe/0x610
[<
ffffffffae3d0666>] process_one_work+0x716/0x1a50
[<
ffffffffae3d05c9>] ? process_one_work+0x679/0x1a50
[<
ffffffffafdd7b6d>] ? _raw_spin_unlock_irq+0x3d/0x60
[<
ffffffffae3cff50>] ? pwq_dec_nr_in_flight+0x2b0/0x2b0
[<
ffffffffae3d1a80>] worker_thread+0xe0/0x1460
[<
ffffffffae3d19a0>] ? process_one_work+0x1a50/0x1a50
[<
ffffffffae3e54c2>] kthread+0x222/0x2e0
[<
ffffffffae3e52a0>] ? kthread_park+0x80/0x80
[<
ffffffffae3e52a0>] ? kthread_park+0x80/0x80
[<
ffffffffae3e52a0>] ? kthread_park+0x80/0x80
[<
ffffffffafdd86aa>] ret_from_fork+0x2a/0x40
Object at
ffff8803fc244088, in cache kmalloc-1024 size: 1024
Allocated:
PID = 71
save_stack_trace+0x1b/0x20
save_stack+0x46/0xd0
kasan_kmalloc+0xad/0xe0
kasan_slab_alloc+0x12/0x20
__kmalloc_track_caller+0x134/0x360
kmemdup+0x20/0x50
brcmf_cfg80211_attach+0x10b/0x3a90 [brcmfmac]
brcmf_bus_start+0x19a/0x9a0 [brcmfmac]
brcmf_pcie_setup+0x1f1a/0x3680 [brcmfmac]
brcmf_fw_request_nvram_done+0x44c/0x11b0 [brcmfmac]
request_firmware_work_func+0x135/0x280
process_one_work+0x716/0x1a50
worker_thread+0xe0/0x1460
kthread+0x222/0x2e0
ret_from_fork+0x2a/0x40
Freed:
PID = 2568
save_stack_trace+0x1b/0x20
save_stack+0x46/0xd0
kasan_slab_free+0x71/0xb0
kfree+0xe8/0x2e0
brcmf_cfg80211_detach+0x62/0xf0 [brcmfmac]
brcmf_detach+0x14a/0x2b0 [brcmfmac]
brcmf_pcie_remove+0x140/0x5d0 [brcmfmac]
brcmf_pcie_pm_leave_D3+0x198/0x2e0 [brcmfmac]
pci_pm_resume+0x186/0x220
dpm_run_callback+0x6e/0x4f0
device_resume+0x1c2/0x670
async_resume+0x1d/0x50
async_run_entry_fn+0xfe/0x610
process_one_work+0x716/0x1a50
worker_thread+0xe0/0x1460
kthread+0x222/0x2e0
ret_from_fork+0x2a/0x40
Memory state around the buggy address:
ffff8803fc243f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8803fc244000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>
ffff8803fc244080: fc fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8803fc244100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8803fc244180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
What is happening is that brcmf_pcie_resume() detects a device that
is no longer responsive and it decides to unbind resulting in a
wiphy_unregister() and wiphy_free() call. Now the wiphy instance
remains allocated, because PM needs to call wiphy_resume() for it.
However, brcmfmac already does a kfree() for the struct
cfg80211_registered_device::ops field. Change the checks in
wiphy_resume() to only access the struct cfg80211_registered_device::ops
if the wiphy instance is still registered at this time.
Cc: stable@vger.kernel.org # 4.10.x, 4.9.x
Reported-by: Daniel J Blueman <daniel@quora.org>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>