Kees Cook <keescook@xxxxxxxxxxxx> writes:
> On Thu, Oct 26, 2023 at 11:19:18PM +0000, Justin Stitt wrote:
>
>> strncpy() is deprecated for use on NUL-terminated destination strings
>> [1] and as such we should prefer more robust and less ambiguous string
>> interfaces.
>>
>> `extra` is clearly supposed to be NUL-terminated which is evident by the
>> manual NUL-byte assignment as well as its immediate usage with strlen().
>>
>> Moreover, let's NUL-pad since there is deliberate effort (48 instances)
>> made elsewhere to zero-out buffers in these getters and setters:
>> 6050 | memset(local->config.nodeName, 0, sizeof(local->config.nodeName));
>> 6130 | memset(local->config.rates, 0, 8);
>> 6139 | memset(local->config.rates, 0, 8);
>> 6414 | memset(key.key, 0, MAX_KEY_SIZE);
>> 6497 | memset(extra, 0, 16);
>> (to be clear, strncpy also NUL-padded -- we are matching that behavior)
>>
>> Considering the above, a suitable replacement is `strscpy_pad` due to
>> the fact that it guarantees both NUL-termination and NUL-padding on the
>> destination buffer.
>>
>> We can also replace the hard-coded size of "16" to IW_ESSID_MAX_SIZE
>> because this function is a wext handler.
>>
>> In wext-core.c we have:
>> static const struct iw_ioctl_description standard_ioctl[] = {
>> ...
>> [IW_IOCTL_IDX(SIOCGIWNICKN)] = {
>> .header_type = IW_HEADER_TYPE_POINT,
>> .token_size = 1,
>> .max_tokens = IW_ESSID_MAX_SIZE,
>> },
>>
>> So the buffer size is (strangely) IW_ESSID_MAX_SIZE
>>
>> Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
>> Link: https://github.com/KSPP/linux/issues/90
>> Cc: linux-hardening@xxxxxxxxxxxxxxx
>> Signed-off-by: Justin Stitt <justinstitt@xxxxxxxxxx>
>
> Looks good; thanks!
>
> Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx>
BTW most likely next week this driver and a bunch of other ancient
drivers will removed:
https://patchwork.kernel.org/project/linux-wireless/list/?series=795639&state=*&order=date
So to avoid unnecessary work on already removed drivers I recommend
using wireless-next as the baseline for wireless patches. Though I'm
still planning to apply this patch in case we ever add the driver back
(I hope not).
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
