[Patch2/3] BSS transition with candidate list

[David Weidenkopf]

Well, upon further review, that line of code looks scary, but it is safe
for the following reasons:

The buffer is ensured to be null terminated up higher in the call chain.
The number of space separated arguments in the buffer is validated higher
in the call chain (although on the sending side of the socket).
The function hwaddr_aton validates that the initial characters are a mac
address.

Therefore it is safe to advance the pointer by the length of a mac address
characters.

I think it is safe as is. FWIW, the api in question is implemented
according to the others in the module.

Regards,
David

On Wed, Aug 3, 2016 at 3:24 PM, David Weidenkopf
<dweidenkopf at cococorp.com> wrote:
> Yes, it appears you are correct. The code should be changed to verify length.
>
> Thanks for your review.
>
> On Wed, Aug 3, 2016 at 1:38 AM,  <michael-dev at fami-braun.de> wrote:
>> I've not tested this patch but when reading
>> hostapd_ctrl_iface_bss_transition it appears to me that the length of cmd is
>> not checked so timerstr and apstr could be out of bounds. Right?
>>
>> Regards,
>> M. Braun
>>
>> Am 29. Juli 2016 17:48:19 MESZ, schrieb David Weidenkopf
>> <dweidenkopf at cococorp.com>:
>>>
>>> This patch extends BSS transition (802.11v) support. It includes a new
>>> simplified BSS Transition function in the CLI command. This function
>>> allows
>>> the user to specify the client station and a target BSS transition
>>> candidate which is included as a neighbor report. The BSS Transition
>>> request packet is then automatically filled in with the appropriate data
>>> for bssid of the target AP, the channel of the target AP, and the
>>> preference value of the AP.
>>>
>>> ________________________________
>>>
>>> Hostap mailing list
>>> Hostap at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/hostap