> It's just a question of where to address this - in the kernel or the supplicant. In a way, I'd rather have the kernel reject it and do the policy of ignoring invalid stuff in the supplicant. The above statement from you made me to rethink for the following check in the patch sent. + if (params->supported_oper_classes_len < 2 || + params->supported_oper_classes_len > 253) + return -EINVAL; Are you fine to return a failure for the invalid length for the supported_oper_classes_len? If yes, then shouldn't we also do the similar check for invalid supported_channels_len ( < 2 ). Regards, Sunil -----Original Message----- From: Johannes Berg [mailto:johannes@xxxxxxxxxxxxxxxx] Sent: Wednesday, October 09, 2013 2:02 PM To: Undekari, Sunil Dutt Cc: j@xxxxxxxxx; linux-wireless@xxxxxxxxxxxxxxx Subject: Re: [PATCH] cfg80211: Pass station supported channel and oper class info to kernel On Wed, 2013-10-09 at 08:19 +0000, Undekari, Sunil Dutt wrote: > Hi Johannes, > > >I guess then wpa_supplicant would have to remove the info - maybe the failure case shouldn't be quite as draconic? Maybe make it ignore any extra trailing byte? > Thanks for your point. > I suppose, returning a failure for the length being less than 2 even after ignoring the trailing byte is not required for the reason that the supported channels is not a mandatory field (at least w.r.t TDLS). It should be fine to just pass the length as 0 to the host driver. Please correct me. It's just a question of where to address this - in the kernel or the supplicant. In a way, I'd rather have the kernel reject it and do the policy of ignoring invalid stuff in the supplicant. johannes ��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
