All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: jianqiang wang <wjq.sec@gmail.com>
Cc: barebox@lists.infradead.org
Subject: Re: Heap overflow vulnerabilities in network implementation of barebox
Date: Mon, 27 May 2024 09:41:13 +0200	[thread overview]
Message-ID: <ZlQ5Ge4r9nP4CCBn@pengutronix.de> (raw)
In-Reply-To: <CAMn3X6NejkLSeyFvJ7Z-0APaUHK8eTWRgFKvbft3SLJp4nO1YQ@mail.gmail.com>

Hi,

On Thu, May 23, 2024 at 06:51:01PM +0200, jianqiang wang wrote:
> Dear Barebox devlopers,
> 
> I found several heap overflow vulnerabilities in Barebox.
> 
> The Barebox implementation assumes that the network packet received is
> less than PKTSIZE, that is 1536 bytes. For example, the /net/net.c
> file ping_reply function assumes that the packet received is 1536
> bytes and allocates a 1536 bytes buffer then copies the packet data
> into the buffer.
> 
> However, in the driver layer, it lacks a proper check of the packet length.
> For example, in drivers/net/cs8900.c cs8900_probe function, it
> allocates a PKTSIZE buffer and assigns it to rx_buf. In cs8900_recv
> function, the length is read from the device register:
> 
> len = readw(priv->regs + CS8900_RTDATA0);
> 
> After that, the data is read from the register in a loop without a
> boundary check.
> The same vulnerability happens to the following drivers:
> 
> drivers/net/ks8851_mll.c function ks8851_rx_frame, it only and the
> packet length with RXFHBCR_CNT_MASK (4095 bytes,) which is not
> consistent with the upper layer length check.
> 
> drivers/net/liteeth.c function liteeth_eth_rx, It checks if the length
> is larger than 2048 which is inconsistent with the upper layer.
> 
> drivers/net/smc911x.c function smc911x_eth_rx. The packet length is
> read from the register without checking.
> 
> It would be good to add a proper and consistent boundary check for
> these drivers otherwise it will lead to potential heap overflow
> vulnerability.

Thanks for noting this. I've just sent a series fixing the drivers you
explicitly mentioned. Additionally I have checked a few other drivers
and it seems at least the smc91111 driver has this issue as well. Are
you aware of other drivers?

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



  reply	other threads:[~2024-05-27  7:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-23 16:51 Heap overflow vulnerabilities in network implementation of barebox jianqiang wang
2024-05-27  7:41 ` Sascha Hauer [this message]
2024-05-27  9:45   ` jianqiang wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZlQ5Ge4r9nP4CCBn@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=wjq.sec@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.