exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Broadcom wl_run_escan Heap Overflow

Broadcom wl_run_escan Heap Overflow
Posted Apr 9, 2017
Authored by Google Security Research, laginimaineb

Broadcom suffers from a heap overflow vulnerability in wl_run_escan when handling WLC_GET_VALID_CHANNELS ioctl results.

tags | advisory, overflow
advisories | CVE-2017-0568
SHA-256 | 291dbbd1b6fa1f4bb1ac9db10257990a591040ae6e962893e5de0d5929b8dab6

Broadcom wl_run_escan Heap Overflow

Change Mirror Download
 Broadcom: Heap overflow in "wl_run_escan" when handling WLC_GET_VALID_CHANNELS ioctl results 

CVE-2017-0568


Broadcom produces Wi-Fi HardMAC SoCs which are used to handle the PHY and MAC layer processing. These chips are present in both mobile devices and Wi-Fi routers, and are capable of handling many Wi-Fi related events without delegating to the host OS. On Android devices, the "bcmdhd" driver is used in order to communicate with the Wi-Fi SoC (also referred to as "dongle").

Along with the regular flow of frames transferred between the host and the dongle, the two communicate with one another via a set of "ioctls" which can be issued to read or write dongle configuration from the host. This information is exchanged using the SDIO "control" channel (SDPCM_CONTROL_CHANNEL) rather than the regular "data" and "glom" channels (which are used to transfer frames).

When the "bcmdhd" driver performs a network scan, it does so by calling "wl_run_escan". In configurations where P2P scan is enabled (non-legacy configurations), the function first fetches the list of allowed channels in the current regulatory domain. The channels are fetched by issuing the WLC_GET_VALID_CHANNELS ioctl to the dongle. This ioctl's results are interpreted as an array of 16-bit values representing channels and a single 32-bit bit value denoting the length of the channel array.

Here is a short snippet from the code handling the P2P scan's logic:

1. u16* default_chan_list = kzalloc(num_chans * sizeof(*default_chan_list), GFP_KERNEL);
2. u32 n_nodfs = 0
3. ...
4. if (!wl_get_valid_channels(ndev, chan_buf, sizeof(chan_buf))) {
5. list = (wl_uint32_list_t *) chan_buf;
6. n_valid_chan = dtoh32(list->count);
7. for (i = 0; i < num_chans; i++)
8. {
9. _freq = request->channels[i]->center_freq;
10. channel = ieee80211_frequency_to_channel(_freq);
11. ...
12. for (j = 0; j < n_valid_chan; j++) {
13. if (channel == (dtoh32(list->element[j])))
14. default_chan_list[n_nodfs++] = channel;
15. }
16. }
17. }

Where "wl_get_valid_channels" is a simple wrapper around the WLC_GET_VALID_CHANNELS ioctl.

An attacker controlling the dongle can re-write the ioctl handling function (since it is entirely RAM-resident), in order to control the results of the ioctl above. This would allow the attacker to return an arbitrarily large value for "list->count". Doing so would cause the internal loop (lines 12-15) to iterate many times, and each time a value matching "channel" is encountered, line 14 would be executed. Since there is no validation to make sure that "n_nodfs" does not exceed the size of "num_chans", this would cause the loop to overflow the allocated chunk for "default_chan_list", corrupting the kernel's memory.

I've been able to statically verify this issue on the "bcmdhd-3.10" driver, and in the corresponding "bcmdhd" driver on the Nexus 5 (hammerhead) and Nexus 6P's (angler) kernels.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.




Found by: laginimaineb

Login or Register to add favorites

File Archive:

August 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Aug 1st
    15 Files
  • 2
    Aug 2nd
    22 Files
  • 3
    Aug 3rd
    0 Files
  • 4
    Aug 4th
    0 Files
  • 5
    Aug 5th
    15 Files
  • 6
    Aug 6th
    11 Files
  • 7
    Aug 7th
    43 Files
  • 8
    Aug 8th
    42 Files
  • 9
    Aug 9th
    36 Files
  • 10
    Aug 10th
    0 Files
  • 11
    Aug 11th
    0 Files
  • 12
    Aug 12th
    27 Files
  • 13
    Aug 13th
    18 Files
  • 14
    Aug 14th
    50 Files
  • 15
    Aug 15th
    33 Files
  • 16
    Aug 16th
    23 Files
  • 17
    Aug 17th
    0 Files
  • 18
    Aug 18th
    0 Files
  • 19
    Aug 19th
    0 Files
  • 20
    Aug 20th
    0 Files
  • 21
    Aug 21st
    0 Files
  • 22
    Aug 22nd
    0 Files
  • 23
    Aug 23rd
    0 Files
  • 24
    Aug 24th
    0 Files
  • 25
    Aug 25th
    0 Files
  • 26
    Aug 26th
    0 Files
  • 27
    Aug 27th
    0 Files
  • 28
    Aug 28th
    0 Files
  • 29
    Aug 29th
    0 Files
  • 30
    Aug 30th
    0 Files
  • 31
    Aug 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close