[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8e70739d-6b5f-9448-d012-05efc38ab988@wanadoo.fr>
Date: Sat, 11 Jan 2020 12:44:22 +0100
From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
To: netdev@...r.kernel.org
Cc: netdev@...r.kernel.org, kernel-janitors@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH][next] ath11k: avoid null pointer dereference when pointer
band is null
Le 11/01/2020 à 10:50, linmiaohe a écrit :
> Colin Ian King <colin.king@...onical.com> wrote:
>> From: Colin Ian King <colin.king@...onical.com>
>>
>> In the unlikely event that cap->supported_bands has neither WMI_HOST_WLAN_2G_CAP set or WMI_HOST_WLAN_5G_CAP set then pointer band is null and a null dereference occurs when assigning
>> band->n_iftype_data. Move the assignment to the if blocks to
>> avoid this. Cleans up static analysis warnings.
>>
>> Addresses-Coverity: ("Explicit null dereference")
>> Fixes: 9f056ed8ee01 ("ath11k: add HE support")
>> Signed-off-by: Colin Ian King <colin.king@...onical.com>
>> ---
>> drivers/net/wireless/ath/ath11k/mac.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
> It looks fine for me. Thanks.
> Reviewed-by: Miaohe Lin <linmiaohe@...wei.com>
Shouldn't there be a
|
- band->n_iftype_data = count; at the end of the patch if the assignment is *moved*? Without it,
'band' (as well as 'count') could be un-initialized, and lead to memory
corruption. Just my 2c. CJ |
Powered by blists - more mailing lists