[PATCH] P2P: WFd: Add wfd_dev_info= field for device found event

Dmitry Shmidt dimitrysh
Mon Nov 25 15:24:08 PST 2013


On Sat, Nov 23, 2013 at 2:42 PM, Jouni Malinen <j at w1.fi> wrote:
> On Fri, Nov 22, 2013 at 04:39:37PM -0800, Dmitry Shmidt wrote:
>> diff --git a/wpa_supplicant/p2p_supplicant.c b/wpa_supplicant/p2p_supplicant.c
>> @@ -1442,16 +1442,27 @@ void wpas_dev_found(void *ctx, const u8 *addr,
>>  #ifndef CONFIG_NO_STDOUT_DEBUG
>>       struct wpa_supplicant *wpa_s = ctx;
>>       char devtype[WPS_DEV_TYPE_BUFSIZE];
>> -
>> +#define WFD_DEV_INFO_SIZE 9
>> +     char wfd_dev_info_hex[2 * WFD_DEV_INFO_SIZE + 1];
>> +     os_memset(wfd_dev_info_hex, 0, sizeof(wfd_dev_info_hex));
>> +#ifdef CONFIG_WIFI_DISPLAY
>> +     if (info->wfd_subelems) {
>> +             wpa_snprintf_hex(wfd_dev_info_hex, sizeof(wfd_dev_info_hex),
>> +                              wpabuf_head(info->wfd_subelems),
>> +                              WFD_DEV_INFO_SIZE);
>
> Where does this assumption of there always being 9 octets of data in the
> full set of WFD elements come from? This also seem to assume that the
> device info would always be the first subelement. This does not look
> safe since the elements parser in p2p_parse_ies() does no such
> validation. This sounds like something that could result in buffer
> overflow based on data received over air and/or result in truncated or
> unexpected information being included in the event.

You are right, issue should be addressed.

>
>>       wpa_msg_global(wpa_s, MSG_INFO, P2P_EVENT_DEVICE_FOUND MACSTR
>>                      " p2p_dev_addr=" MACSTR
>>                      " pri_dev_type=%s name='%s' config_methods=0x%x "
>> -                    "dev_capab=0x%x group_capab=0x%x",
>> +                    "dev_capab=0x%x group_capab=0x%x%s%s",
>>                      MAC2STR(addr), MAC2STR(info->p2p_device_addr),
>>                      wps_dev_type_bin2str(info->pri_dev_type, devtype,
>>                                           sizeof(devtype)),
>> -             info->device_name, info->config_methods,
>> -             info->dev_capab, info->group_capab);
>> +                    info->device_name, info->config_methods,
>> +                    info->dev_capab, info->group_capab,
>> +                    wfd_dev_info_hex[0] ? " wfd_dev_info=0x" : "",
>> +                    wfd_dev_info_hex);
>
> Why would this information be needed in the P2P-DEVICE-FOUND event? It
> is already available from the P2P_PEER command and that information is
> actually provided in full rather than this type of fixed length of 9
> assumption.
>
> If there is real need to get the Wi-Fi Display information added to the
> P2P-DEVICE-FOUND event, this would need to be fixed to validate the
> data, parse the subelements, and only include the needed information. I
> guess that length 9 is referring to the current total size of the WFD
> Device Information subelement. If that is the information you want, more
> appropriate operation would be to parse that element and include just
> the six octets of payload in it.

Done:
http://patchwork.ozlabs.org/patch/294137/

>
> If you want to maintain this wasteful format with 0x prefix and id+len
> fields included for backwards compatibility with existing consumers of
> such data, the implementation here would need to verify that the first
> sublement is indeed WFD Device Info and only in that case, add this
> data. (Or for more completeness, find the WFD Device Info even if it is
> not the first subelement.)

Adding this info allows to see if WFD exists without using P2P_PEER call per
found P2P device.

>
> --
> Jouni Malinen                                            PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap



More information about the Hostap mailing list