netdev - Re: [PATCH] rtlwifi: rtl8192se firmware load can overflow target buffer

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 linux-cve-announce 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]

Message-ID: <4F331967.3070900@lwfinger.net>
Date:	Wed, 08 Feb 2012 18:55:03 -0600
From:	Larry Finger <Larry.Finger@...inger.net>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	Tim Gardner <tim.gardner@...onical.com>,
	Chaoming Li <chaoming_li@...lsil.com.cn>,
	"John W. Linville" <linville@...driver.com>,
	linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rtlwifi: rtl8192se firmware load can overflow target
 buffer

On 02/08/2012 03:45 PM, Ben Hutchings wrote:
> On Wed, 2012-02-08 at 14:08 -0700, Tim Gardner wrote:
>> The firmware file size check does not use the
>> correct limit.
>>
>> Cc: Larry Finger<Larry.Finger@...inger.net>
>> Cc: Chaoming Li<chaoming_li@...lsil.com.cn>
>> Cc: John W. Linville<linville@...driver.com>
>> Cc: linux-wireless@...r.kernel.org
>> Cc: netdev@...r.kernel.org
>> Cc: linux-kernel@...r.kernel.org
>> Signed-off-by: Tim Gardner<tim.gardner@...onical.com>
>> ---
>>   drivers/net/wireless/rtlwifi/rtl8192se/fw.h |    3 ++-
>>   drivers/net/wireless/rtlwifi/rtl8192se/sw.c |    2 +-
>>   2 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/fw.h b/drivers/net/wireless/rtlwifi/rtl8192se/fw.h
>> index babe85d..5c377fc 100644
>> --- a/drivers/net/wireless/rtlwifi/rtl8192se/fw.h
>> +++ b/drivers/net/wireless/rtlwifi/rtl8192se/fw.h
>> @@ -30,6 +30,7 @@
>>   #define __REALTEK_FIRMWARE92S_H__
>>
>>   #define RTL8190_MAX_FIRMWARE_CODE_SIZE		64000
>> +#define RTL8190_MAX_RAW_FIRMWARE_CODE_SIZE	164000
>>   #define RTL8190_CPU_START_OFFSET		0x80
>>   /* Firmware Local buffer size. 64k */
>>   #define	MAX_FIRMWARE_CODE_SIZE			0xFF00
>> @@ -217,7 +218,7 @@ struct rt_firmware {
>>   	u8 fw_emem[RTL8190_MAX_FIRMWARE_CODE_SIZE];
>>   	u32 fw_imem_len;
>>   	u32 fw_emem_len;
>> -	u8 sz_fw_tmpbuffer[164000];
>> +	u8 sz_fw_tmpbuffer[RTL8190_MAX_RAW_FIRMWARE_CODE_SIZE];
>>   	u32 sz_fw_tmpbufferlen;
>>   	u16 cmdpacket_fragthresold;
>>   };
>> diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
>> index ca38dd9..155da0a 100644
>> --- a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
>> +++ b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
>> @@ -105,7 +105,7 @@ static void rtl92se_fw_cb(const struct firmware *firmware, void *context)
>>   		rtlpriv->max_fw_size = 0;
>>   		return;
>>   	}
>> -	if (firmware->size>  rtlpriv->max_fw_size) {
>> +	if (firmware->size>= RTL8190_MAX_RAW_FIRMWARE_CODE_SIZE) {
>
> This appears to reject a firmware blob which is exactly the maximum
> size, which looks wrong.  Also doesn't this make the max_fw_size field
> redundant?
>
> Ben.
>
>>   		RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
>>   			 "Firmware is too big!\n");
>>   		release_firmware(firmware);
>

For all the drivers under rtlwifi, max_fw_size is set to zero whenever the 
required firmware file is not found. In the original version with synchronous 
firmware loading, the existence of the required file and it's size were known 
immediately, but with the asynch loading now used, that info is not known until 
later. Thus a parameter is used. In addition, rtl8192ce, rtl8192cu, and 
rtl8192de all share the same asynchronous loading callback routine, but each has 
a different firmware size. The parameter max_fw_size contains that info as well.

The patch is NACKed.

Larry
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html