Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d06d2e44-7403-7e7e-1936-588139bf448e@gmail.com>
Date:   Wed, 11 Jan 2023 10:54:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.6.1
Subject: Re: [PATCH] rndis_wlan: Prevent buffer overflow in rndis_query_oid
To:     Alexander H Duyck <alexander.duyck@gmail.com>, kvalo@kernel.org,
        jussi.kivilinna@iki.fi, davem@davemloft.net
Cc:     edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
        linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, Greg KH <greg@kroah.com>
References: <20230110173007.57110-1-szymon.heidrich@gmail.com>
 <ece5f6a7fad9eb55d0fbf97c6227571e887c2c33.camel@gmail.com>
Content-Language: en-US
From:   Szymon Heidrich <szymon.heidrich@gmail.com>
In-Reply-To: <ece5f6a7fad9eb55d0fbf97c6227571e887c2c33.camel@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 10/01/2023 20:39, Alexander H Duyck wrote:
> On Tue, 2023-01-10 at 18:30 +0100, Szymon Heidrich wrote:
>> Since resplen and respoffs are signed integers sufficiently
>> large values of unsigned int len and offset members of RNDIS
>> response will result in negative values of prior variables.
>> This may be utilized to bypass implemented security checks
>> to either extract memory contents by manipulating offset or
>> overflow the data buffer via memcpy by manipulating both
>> offset and len.
>>
>> Additionally assure that sum of resplen and respoffs does not
>> overflow so buffer boundaries are kept.
>>
>> Fixes: 80f8c5b434f9 ("rndis_wlan: copy only useful data from rndis_command respond")
>> Signed-off-by: Szymon Heidrich <szymon.heidrich@gmail.com>
>> ---
>>  drivers/net/wireless/rndis_wlan.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
>> index 82a7458e0..d7fc05328 100644
>> --- a/drivers/net/wireless/rndis_wlan.c
>> +++ b/drivers/net/wireless/rndis_wlan.c
>> @@ -697,7 +697,7 @@ static int rndis_query_oid(struct usbnet *dev, u32 oid, void *data, int *len)
>>  		struct rndis_query_c	*get_c;
>>  	} u;
>>  	int ret, buflen;
>> -	int resplen, respoffs, copylen;
>> +	u32 resplen, respoffs, copylen;
> 
> Rather than a u32 why not just make it an size_t? The advantage is that
> is the native type for all the memory allocation and copying that takes
> place in the function so it would avoid having to cast between u32 and
> size_t.
 
My sole intention with this patch was to address the exploitable overflow
with minimal chance of introducing any extra issues.
Sure some things probably could be done differently, but I would stick to
the choices made by original authors of this driver, especially since Greg
mentioned that RNDIS support generally should be dropped at some point.

> Also why not move buflen over to the unsigned integer category with the
> other values you stated were at risk of overflow?
> 
>>  
>>  	buflen = *len + sizeof(*u.get);
>>  	if (buflen < CONTROL_BUFFER_SIZE)
> 
> For example, this line here is comparing buflen to a fixed constant. If
> we are concerned about overflows this could be triggering an integer
> overflow resulting in truncation assuming *len is close to the roll-
> over threshold.

I'm not sure how this would be exploitable since len is controlled by the
developer rather than potential attacker, at least in existing code. Please
correct me in case I'm wrong.
 
> By converting to a size_t we would most likely end up blowing up on the
> kmalloc and instead returning an -ENOMEM.
> 
>> @@ -740,7 +740,7 @@ static int rndis_query_oid(struct usbnet *dev, u32 oid, void *data, int *len)
> 
> Also with any type change such as this I believe you would also need to
> update the netdev_dbg statement that displays respoffs and the like to
> account for the fact that you are now using an unsigned value.
> Otherwise I believe %d will display the value as a signed integer
> value.
> 
>>  			goto exit_unlock;
>>  		}
>>  
>> -		if ((resplen + respoffs) > buflen) {
>> +		if (resplen > (buflen - respoffs)) {
>>  			/* Device would have returned more data if buffer would
>>  			 * have been big enough. Copy just the bits that we got.
>>  			 */
> 
> Actually you should be able to simplfy this further. Assuming resplen,
> buflen and respoffs all the same type this entire if statement could be
> broken down into:
> 		copylen = min(resplen, buflen - respoffs);
> 
> 

Agree, yet I would prefer to avoid any non-essential changes to keep the risk
of introducing errors as low as possible. I intentionally refrained from any
additional modifications. Is this acceptable?

Thank you for your review, I really appreciate all the suggestions.