[PATCH] hippi: fix possible buffer overflow caused by bad DMA value in rr_start_xmit()

Huai-Yuan Liu posted 1 patch 1 year, 5 months ago
There is a newer version of this series
drivers/net/hippi/rrunner.c | 6 ++++++
1 file changed, 6 insertions(+)
[PATCH] hippi: fix possible buffer overflow caused by bad DMA value in rr_start_xmit()
Posted by Huai-Yuan Liu 1 year, 5 months ago
The value rrpriv->info->tx_ctrl is stored in DMA memory, and assigned to
txctrl. However, txctrl->pi can be modified by malicious hardware at any
time. Because txctrl->pi is assigned to index, buffer overflow may
occur when the code "rrpriv->tx_skbuff[index]" is executed.

To address this issue, ensure index is checked.

Fixes: f33a7251c825 ("hippi: switch from 'pci_' to 'dma_' API")
Signed-off-by: Huai-Yuan Liu <qq810974084@gmail.com>
---
V2:
* In patch V2, we remove the first condition in if statement and use
  netdev_err() instead of printk().
  Thanks Paolo Abeni for helpful advice.
V3:
* In patch V3, we stop the queue before return BUSY.
  Thanks to Jakub Kicinski for his advice.
V4:
* In patch V4, we revise the wording in the description.
  Thanks to Markus Elfring for pointing this out.
---
 drivers/net/hippi/rrunner.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/hippi/rrunner.c b/drivers/net/hippi/rrunner.c
index aa8f828a0ae7..f4da342dd5cc 100644
--- a/drivers/net/hippi/rrunner.c
+++ b/drivers/net/hippi/rrunner.c
@@ -1440,6 +1440,12 @@ static netdev_tx_t rr_start_xmit(struct sk_buff *skb,
 	txctrl = &rrpriv->info->tx_ctrl;
 
 	index = txctrl->pi;
+	if (index >= TX_RING_ENTRIES) {
+		netdev_err(dev, "invalid index value %02x\n", index);
+		netif_stop_queue(dev);
+		spin_unlock_irqrestore(&rrpriv->lock, flags);
+		return NETDEV_TX_BUSY;
+	}
 
 	rrpriv->tx_skbuff[index] = skb;
 	set_rraddr(&rrpriv->tx_ring[index].addr,
-- 
2.34.1
Re: [PATCH] hippi: fix possible buffer overflow caused by bad DMA value in rr_start_xmit()
Posted by Eric Dumazet 1 year, 5 months ago
On Tue, Jun 25, 2024 at 9:52 AM Huai-Yuan Liu <qq810974084@gmail.com> wrote:
>
> The value rrpriv->info->tx_ctrl is stored in DMA memory, and assigned to
> txctrl. However, txctrl->pi can be modified by malicious hardware at any
> time. Because txctrl->pi is assigned to index, buffer overflow may
> occur when the code "rrpriv->tx_skbuff[index]" is executed.

How txctrl->pi can be modified by malicious hardware ? This is host
memory, not mapped to the device.


>
> To address this issue, ensure index is checked.
>
> Fixes: f33a7251c825 ("hippi: switch from 'pci_' to 'dma_' API")

Is it just me or this Fixes: tag is not relevant ?

> Signed-off-by: Huai-Yuan Liu <qq810974084@gmail.com>
> ---
> V2:
> * In patch V2, we remove the first condition in if statement and use
>   netdev_err() instead of printk().
>   Thanks Paolo Abeni for helpful advice.
> V3:
> * In patch V3, we stop the queue before return BUSY.
>   Thanks to Jakub Kicinski for his advice.
> V4:
> * In patch V4, we revise the wording in the description.
>   Thanks to Markus Elfring for pointing this out.
> ---
>  drivers/net/hippi/rrunner.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/hippi/rrunner.c b/drivers/net/hippi/rrunner.c
> index aa8f828a0ae7..f4da342dd5cc 100644
> --- a/drivers/net/hippi/rrunner.c
> +++ b/drivers/net/hippi/rrunner.c
> @@ -1440,6 +1440,12 @@ static netdev_tx_t rr_start_xmit(struct sk_buff *skb,
>         txctrl = &rrpriv->info->tx_ctrl;
>
>         index = txctrl->pi;
> +       if (index >= TX_RING_ENTRIES) {
> +               netdev_err(dev, "invalid index value %02x\n", index);
> +               netif_stop_queue(dev);
> +               spin_unlock_irqrestore(&rrpriv->lock, flags);
> +               return NETDEV_TX_BUSY;
> +       }

When seeing this patch, my initial reaction was : array_index_nospec()
is missing.

But then :

If a malicious hardware can control txctl->pi, then it will cause
multiple UAF or skb leaks if txctrl->pi
is kept below TX_RING_ENTRIES.

This driver should keep a trusted copy of txctrl->pi field, only seen by itself,
and not read it from the untrusted device.

Otherwise, this patch is only adding a lot of confusion.