lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 13 Apr 2021 16:25:47 -0500
From:   "Gustavo A. R. Silva" <gustavo@...eddedor.com>
To:     Kees Cook <keescook@...omium.org>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>
Cc:     linux-kernel@...r.kernel.org, Kalle Valo <kvalo@...eaurora.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-hardening@...r.kernel.org
Subject: Re: [PATCH v2 2/2][next] wl3501_cs: Fix out-of-bounds warning in
 wl3501_mgmt_join

Hi all!

On 4/7/21 14:02, Kees Cook wrote:
> On Wed, Mar 31, 2021 at 04:45:34PM -0500, Gustavo A. R. Silva wrote:
>> Fix the following out-of-bounds warning by enclosing
>> some structure members into new struct req:
>>
>> arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [39, 108] from the object at 'sig' is out of the bounds of referenced subobject 'beacon_period' with type 'short unsigned int' at offset 36 [-Warray-bounds]
>>
>> Refactor the code, accordingly:
>>
>> $ pahole -C wl3501_join_req drivers/net/wireless/wl3501_cs.o
>> struct wl3501_join_req {
>> 	u16                        next_blk;             /*     0     2 */
>> 	u8                         sig_id;               /*     2     1 */
>> 	u8                         reserved;             /*     3     1 */
>> 	struct iw_mgmt_data_rset   operational_rset;     /*     4    10 */
>> 	u16                        reserved2;            /*    14     2 */
>> 	u16                        timeout;              /*    16     2 */
>> 	u16                        probe_delay;          /*    18     2 */
>> 	u8                         timestamp[8];         /*    20     8 */
>> 	u8                         local_time[8];        /*    28     8 */
>> 	struct {
>> 		u16                beacon_period;        /*    36     2 */
>> 		u16                dtim_period;          /*    38     2 */
>> 		u16                cap_info;             /*    40     2 */
>> 		u8                 bss_type;             /*    42     1 */
>> 		u8                 bssid[6];             /*    43     6 */
>> 		struct iw_mgmt_essid_pset ssid;          /*    49    34 */
>> 		/* --- cacheline 1 boundary (64 bytes) was 19 bytes ago --- */
>> 		struct iw_mgmt_ds_pset ds_pset;          /*    83     3 */
>> 		struct iw_mgmt_cf_pset cf_pset;          /*    86     8 */
>> 		struct iw_mgmt_ibss_pset ibss_pset;      /*    94     4 */
>> 		struct iw_mgmt_data_rset bss_basic_rset; /*    98    10 */
>> 	} req;                                           /*    36    72 */
> 
> This section is the same as a large portion of struct wl3501_scan_confirm:
> 
> struct wl3501_scan_confirm {
>         u16                         next_blk;
>         u8                          sig_id;
>         u8                          reserved;
>         u16                         status;
>         char                        timestamp[8];
>         char                        localtime[8];
> 
> from here
>         u16                         beacon_period;
>         u16                         dtim_period;
>         u16                         cap_info;
>         u8                          bss_type;
>         u8                          bssid[ETH_ALEN];
>         struct iw_mgmt_essid_pset   ssid;
>         struct iw_mgmt_ds_pset      ds_pset;
>         struct iw_mgmt_cf_pset      cf_pset;
>         struct iw_mgmt_ibss_pset    ibss_pset;
>         struct iw_mgmt_data_rset    bss_basic_rset;
> through here
> 
>         u8                          rssi;
> };
> 
> It seems like maybe extracting that and using it in both structures
> would make more sense?

If I do this, I would therefore have to make a bunch of other changes,
accordingly. I'm OK with that but I'd like to have the opinion of the
maintainers on all this. So, I will go and ping them from the cover
letter of this series with the hope that we can get some feedback from
them. :) They have been silent for a couple of weeks now.

> 
>>
>> 	/* size: 108, cachelines: 2, members: 10 */
>> 	/* last cacheline: 44 bytes */
>> };
>>
>> The problem is that the original code is trying to copy data into a
>> bunch of struct members adjacent to each other in a single call to
>> memcpy(). Now that a new struct _req_ enclosing all those adjacent
>> members is introduced, memcpy() doesn't overrun the length of
>> &sig.beacon_period, because the address of the new struct object
>> _req_ is used as the destination, instead.
>>
>> Also, this helps with the ongoing efforts to enable -Warray-bounds and
>> avoid confusing the compiler.
>>
>> Link: https://github.com/KSPP/linux/issues/109
>> Reported-by: kernel test robot <lkp@...el.com>
>> Build-tested-by: kernel test robot <lkp@...el.com>
>> Link: https://lore.kernel.org/lkml/60641d9b.2eNLedOGSdcSoAV2%25lkp@intel.com/
>> Signed-off-by: Gustavo A. R. Silva <gustavoars@...nel.org>
>> ---
>> Changes in v2:
>>  - None.
>>
>>  drivers/net/wireless/wl3501.h    | 22 ++++++++++++----------
>>  drivers/net/wireless/wl3501_cs.c |  4 ++--
>>  2 files changed, 14 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/net/wireless/wl3501.h b/drivers/net/wireless/wl3501.h
>> index ef9d605d8c88..774d8cac046d 100644
>> --- a/drivers/net/wireless/wl3501.h
>> +++ b/drivers/net/wireless/wl3501.h
>> @@ -389,16 +389,18 @@ struct wl3501_join_req {
>>  	u16			    probe_delay;
>>  	u8			    timestamp[8];
>>  	u8			    local_time[8];
>> -	u16			    beacon_period;
>> -	u16			    dtim_period;
>> -	u16			    cap_info;
>> -	u8			    bss_type;
>> -	u8			    bssid[ETH_ALEN];
>> -	struct iw_mgmt_essid_pset   ssid;
>> -	struct iw_mgmt_ds_pset	    ds_pset;
>> -	struct iw_mgmt_cf_pset	    cf_pset;
>> -	struct iw_mgmt_ibss_pset    ibss_pset;
>> -	struct iw_mgmt_data_rset    bss_basic_rset;
>> +	struct {
>> +		u16			    beacon_period;
>> +		u16			    dtim_period;
>> +		u16			    cap_info;
>> +		u8			    bss_type;
>> +		u8			    bssid[ETH_ALEN];
>> +		struct iw_mgmt_essid_pset   ssid;
>> +		struct iw_mgmt_ds_pset	    ds_pset;
>> +		struct iw_mgmt_cf_pset	    cf_pset;
>> +		struct iw_mgmt_ibss_pset    ibss_pset;
>> +		struct iw_mgmt_data_rset    bss_basic_rset;
>> +	} req;
>>  };
>>  
>>  struct wl3501_join_confirm {
>> diff --git a/drivers/net/wireless/wl3501_cs.c b/drivers/net/wireless/wl3501_cs.c
>> index e149ef81d6cc..399d3bd2ae76 100644
>> --- a/drivers/net/wireless/wl3501_cs.c
>> +++ b/drivers/net/wireless/wl3501_cs.c
>> @@ -590,7 +590,7 @@ static int wl3501_mgmt_join(struct wl3501_card *this, u16 stas)
>>  	struct wl3501_join_req sig = {
>>  		.sig_id		  = WL3501_SIG_JOIN_REQ,
>>  		.timeout	  = 10,
>> -		.ds_pset = {
>> +		.req.ds_pset = {
>>  			.el = {
>>  				.id  = IW_MGMT_INFO_ELEMENT_DS_PARAMETER_SET,
>>  				.len = 1,
>> @@ -599,7 +599,7 @@ static int wl3501_mgmt_join(struct wl3501_card *this, u16 stas)
>>  		},
>>  	};
>>  
>> -	memcpy(&sig.beacon_period, &this->bss_set[stas].beacon_period, 72);
>> +	memcpy(&sig.req, &this->bss_set[stas].beacon_period, sizeof(sig.req));
> 
> If not, then probably something like this should be added to make sure
> nothing unexpected happens to change structure sizes:
> 
> BUILD_BUG_ON(sizeof(sig.req) != 72);

Yep, this is sensible.

Thanks for the feedback!
--
Gustavo

> 
>>  	return wl3501_esbq_exec(this, &sig, sizeof(sig));
>>  }
>>  
>> -- 
>> 2.27.0
>>
> 

Powered by blists - more mailing lists