Re: [PATCH net v2 1/1] net: ethernet: lantiq_etop: fix memory disclosure

From: Aleksander Jan Bajkowski
Date: Mon Sep 23 2024 - 17:08:43 EST


Hi Florian,


On 23.09.2024 20:21, Florian Fainelli wrote:
On 9/21/24 03:58, Aleksander Jan Bajkowski wrote:
When applying padding, the buffer is not zeroed, which results in memory
disclosure. The mentioned data is observed on the wire. This patch uses
skb_put_padto() to pad Ethernet frames properly. The mentioned function
zeroes the expanded buffer.

In case the packet cannot be padded it is silently dropped. Statistics
are also not incremented. This driver does not support statistics in the
old 32-bit format or the new 64-bit format. These will be added in the
future. In its current form, the patch should be easily backported to
stable versions.

Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets
in hardware, so software padding must be applied.

Fixes: 504d4721ee8e ("MIPS: Lantiq: Add ethernet driver")
Signed-off-by: Aleksander Jan Bajkowski <olek2@xxxxx>
---
  drivers/net/ethernet/lantiq_etop.c | 11 ++++++-----
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/lantiq_etop.c b/drivers/net/ethernet/lantiq_etop.c
index 3c289bfe0a09..36f1e3c93ca5 100644
--- a/drivers/net/ethernet/lantiq_etop.c
+++ b/drivers/net/ethernet/lantiq_etop.c
@@ -477,11 +477,11 @@ ltq_etop_tx(struct sk_buff *skb, struct net_device *dev)
      struct ltq_etop_priv *priv = netdev_priv(dev);
      struct ltq_etop_chan *ch = &priv->ch[(queue << 1) | 1];
      struct ltq_dma_desc *desc = &ch->dma.desc_base[ch->dma.desc];
-    int len;
      unsigned long flags;
      u32 byte_offset;
  -    len = skb->len < ETH_ZLEN ? ETH_ZLEN : skb->len;
+    if (skb_put_padto(skb, ETH_ZLEN))
+        return NETDEV_TX_OK;

You should consider continuing to use the temporary variable 'len' here, and just re-assign it after the call to skb_put_padto() and avoid introducing potential user-after-free near the point where you program the buffer length into the HW. This also minimizes the amount of lines to review.

To the best of my knowledge, the skb is not released until the DMA finishes the transfer.
Then the ltq_etop_poll_tx() function is called, which releases the skb. Can you explain
what sequence of events can lead to a use-after-free error?

-->ltq_etop_tx()
     |
     | (dma irq fires)
     |
     -->ltq_etop_dma_irq()
          |
          | (napi task schedule)
          |
          -->ltq_etop_poll_tx()
               |
               |
               |
               -->dev_kfree_skb_any()

Regards