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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <73ef03a1607f221c7939cb0646c17c5435dcecd1.camel@redhat.com>
Date: Tue, 05 Dec 2023 09:04:11 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Oliver Neukum <oneukum@...e.com>, dmitry.bezrukov@...antia.com, 
 marcinguy@...il.com, davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org,  linux-usb@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCHv2] USB: gl620a: check for rx buffer overflow

On Wed, 2023-11-22 at 10:52 +0100, Oliver Neukum wrote:
> The driver checks for a single package overflowing
> maximum size. That needs to be done, but it is not
> enough. As a single transmission can contain a high
> number of packets, we also need to check whether
> the aggregate of messages in itself short enough
> overflow the buffer.
> That is easiest done by checking that the current
> packet does not overflow the buffer.
> 
> Signed-off-by: Oliver Neukum <oneukum@...e.com>

This looks like a bugfix, so a suitable Fixes tag should be included.

> ---
> 
> v2: corrected typo in commit message
>  
>  drivers/net/usb/gl620a.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/usb/gl620a.c b/drivers/net/usb/gl620a.c
> index 46af78caf457..d33ae15abdc1 100644
> --- a/drivers/net/usb/gl620a.c
> +++ b/drivers/net/usb/gl620a.c
> @@ -104,6 +104,10 @@ static int genelink_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
>  			return 0;
>  		}
>  
> +		/* we also need to check for overflowing the buffer */
> +		if (size > skb->len)
> +			return 0;

I think the above is not strict enough: at this point skb->data points
to the gl_packet header. The first 4 bytes in skb are gl_packet-
>packet_length. To ensure an overflow is avoided you should check for:

		if (size + 4 > skb->len)

likely with a describing comment.

Cheers,

Paolo


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ