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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxx>: >>> >>> 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@xxxxxxxxxxxxxxxxxxx >>> http://lists.infradead.org/mailman/listinfo/hostap _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
