linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@kernel.org>
To: Arend Van Spriel <arend.vanspriel@broadcom.com>
Cc: Minsuk Kang <linuxlovemin@yonsei.ac.kr>,
	<linux-wireless@vger.kernel.org>, <dokyungs@yonsei.ac.kr>,
	<jisoo.jang@yonsei.ac.kr>, kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v2] wifi: brcmfmac: Fix potential slab-out-of-bounds read in brcmf_inform_single_bss()
Date: Thu, 22 Dec 2022 18:17:38 +0200	[thread overview]
Message-ID: <87bknvza3h.fsf@kernel.org> (raw)
In-Reply-To: <1853a9d00b0.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com> (Arend Van Spriel's message of "Thu, 22 Dec 2022 17:14:06 +0100")

Arend Van Spriel <arend.vanspriel@broadcom.com> writes:

> On December 22, 2022 4:55:31 PM Kalle Valo <kvalo@kernel.org> wrote:
>
>> Minsuk Kang <linuxlovemin@yonsei.ac.kr> wrote:
>>
>>> This patch fixes a slab-out-of-bounds read in brcmfmac that occurs in
>>> cfg80211_find_elem_match() called from brcmf_inform_single_bss() when
>>> the offset and length values of information elements provided by the
>>> device exceed the boundary of the escan buffer that contains information
>>> elements. The patch adds a check that makes the function return -EINVAL
>>> if that is the case. Note that the negative return is handled by the
>>> caller, brcmf_inform_bss().
>>>
>>> Found by a modified version of syzkaller.
>>>
>>> ==================================================================
>>> BUG: KASAN: slab-out-of-bounds in cfg80211_find_elem_match+0x164/0x180
>>> Read of size 1 at addr ffff888018f0fde9 by task kworker/0:2/1896
>>>
>>> CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G           O      5.14.0+ #139
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>>> rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
>>> Workqueue: events brcmf_fweh_event_worker
>>> Call Trace:
>>> dump_stack_lvl+0x8e/0xd1
>>> print_address_description.constprop.0.cold+0x93/0x334
>>> ? cfg80211_find_elem_match+0x164/0x180
>>> kasan_report.cold+0x79/0xd5
>>> ? cfg80211_find_elem_match+0x164/0x180
>>> cfg80211_find_elem_match+0x164/0x180
>>> cfg80211_get_bss_channel+0x69/0x320
>>> cfg80211_inform_single_bss_data+0x1a6/0x1060
>>> ? cfg80211_bss_update+0x1e20/0x1e20
>>> ? rcu_read_lock_sched_held+0xa1/0xd0
>>> ? rcu_read_lock_bh_held+0xb0/0xb0
>>> ? find_held_lock+0x2d/0x110
>>> ? cfg80211_inform_bss_data+0xcb/0x160
>>> cfg80211_inform_bss_data+0xcb/0x160
>>> ? cfg80211_parse_mbssid_data+0x1540/0x1540
>>> ? kvm_clock_get_cycles+0x14/0x20
>>> ? ktime_get_with_offset+0x2b9/0x450
>>> brcmf_inform_single_bss+0x36d/0x4d0
>>> ? brcmf_notify_mic_status+0xb0/0xb0
>>> ? __lock_acquire+0x181f/0x5790
>>> ? brcmf_p2p_cancel_remain_on_channel+0x30/0x30
>>> brcmf_inform_bss+0x131/0x210
>>> brcmf_cfg80211_escan_handler+0x779/0xd20
>>> ? rcu_read_lock_bh_held+0xb0/0xb0
>>> ? lock_acquire+0x19d/0x4e0
>>> ? find_held_lock+0x2d/0x110
>>> ? brcmf_cfg80211_escan_timeout_worker+0x60/0x60
>>> ? brcmf_fweh_event_worker+0x249/0xc00
>>> ? mark_held_locks+0x9f/0xe0
>>> ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
>>> ? brcmf_cfg80211_escan_timeout_worker+0x60/0x60
>>> brcmf_fweh_call_event_handler.isra.0+0x90/0x100
>>> brcmf_fweh_event_worker+0x117/0xc00
>>> ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100
>>> ? rcu_read_lock_sched_held+0xa1/0xd0
>>> ? rcu_read_lock_bh_held+0xb0/0xb0
>>> ? lockdep_hardirqs_on_prepare+0x273/0x3e0
>>> process_one_work+0x92b/0x1460
>>> ? pwq_dec_nr_in_flight+0x330/0x330
>>> ? rwlock_bug.part.0+0x90/0x90
>>> worker_thread+0x95/0xe00
>>> ? __kthread_parkme+0x115/0x1e0
>>> ? process_one_work+0x1460/0x1460
>>> kthread+0x3a1/0x480
>>> ? set_kthread_struct+0x120/0x120
>>> ret_from_fork+0x1f/0x30
>>>
>>> The buggy address belongs to the page:
>>> page:ffffea000063c000 refcount:1 mapcount:0
>>> mapping:0000000000000000 index:0x0 pfn:0x18f00
>>> head:ffffea000063c000 order:4 compound_mapcount:0 compound_pincount:0
>>> flags: 0x100000000010000(head|node=0|zone=1)
>>> raw: 0100000000010000 0000000000000000 dead000000000122 0000000000000000
>>> raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
>>> page dumped because: kasan: bad access detected
>>> page_owner tracks the page as allocated
>>> page last allocated via order 4, migratetype Unmovable, gfp_mask
>>> 0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), pid 1896, ts
>>> 44510886600, free_ts 0
>>> prep_new_page+0x1aa/0x240
>>> get_page_from_freelist+0x159a/0x27c0
>>> __alloc_pages+0x2da/0x6a0
>>> alloc_pages+0xec/0x1e0
>>> kmalloc_order+0x39/0xf0
>>> kmalloc_order_trace+0x19/0x120
>>> brcmf_cfg80211_attach+0x5c9/0x3fd0
>>> brcmf_attach+0x389/0xd40
>>> brcmf_usb_probe+0x12de/0x1690
>>> usb_probe_interface+0x2aa/0x760
>>> really_probe+0x205/0xb70
>>> __driver_probe_device+0x311/0x4b0
>>> driver_probe_device+0x4e/0x150
>>> __device_attach_driver+0x1cc/0x2a0
>>> bus_for_each_drv+0x156/0x1d0
>>> __device_attach+0x23f/0x3a0
>>> page_owner free stack trace missing
>>>
>>> Memory state around the buggy address:
>>> ffff888018f0fc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> ffff888018f0fd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>> ffff888018f0fd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 fe fe fe
>>>                                                  ^
>>> ffff888018f0fe00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
>>> ffff888018f0fe80: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
>>> ==================================================================
>>>
>>> Reported-by: Dokyung Song <dokyungs@yonsei.ac.kr>
>>> Reported-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
>>> Reported-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
>>> Reported-by: kernel test robot <lkp@intel.com>
>>> Signed-off-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
>>
>> Can someone review this?
>
> Will have to see the bigger picture. Probably have time to do that
> later today.

Thanks, and no rush.

> What's the deadline? ;-)

After looking at the crystall ball[1] I would say around February 5th to
get this to v6.3 via -next ;)

[1] https://phb-crystal-ball.sipsolutions.net/

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

  reply	other threads:[~2022-12-22 16:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16 14:58 [PATCH v2] wifi: brcmfmac: Fix potential slab-out-of-bounds read in brcmf_inform_single_bss() Minsuk Kang
2022-12-22 15:55 ` Kalle Valo
2022-12-22 16:14   ` Arend Van Spriel
2022-12-22 16:17     ` Kalle Valo [this message]
2023-02-27 15:18 ` Kalle Valo
2023-02-27 18:59   ` Arend Van Spriel
2023-02-27 20:02     ` Arend van Spriel
2023-02-27 19:59 ` Arend Van Spriel

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=87bknvza3h.fsf@kernel.org \
    --to=kvalo@kernel.org \
    --cc=arend.vanspriel@broadcom.com \
    --cc=dokyungs@yonsei.ac.kr \
    --cc=jisoo.jang@yonsei.ac.kr \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linuxlovemin@yonsei.ac.kr \
    --cc=lkp@intel.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).