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

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

[Aleksander Jan Bajkowski]

Changes in v2:
 - clarified questions about statistics in the commit description
 - rebased on current master

Aleksander Jan Bajkowski (1):
  net: ethernet: lantiq_etop: fix memory disclosure

 drivers/net/ethernet/lantiq_etop.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

-- 
2.39.5

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

[Aleksander Jan Bajkowski]

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@wp.pl>
---
 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;
 
 	if ((desc->ctl & (LTQ_DMA_OWN | LTQ_DMA_C)) || ch->skb[ch->dma.desc]) {
 		netdev_err(dev, "tx ring full\n");
@@ -496,12 +496,13 @@ ltq_etop_tx(struct sk_buff *skb, struct net_device *dev)
 	netif_trans_update(dev);
 
 	spin_lock_irqsave(&priv->lock, flags);
-	desc->addr = ((unsigned int)dma_map_single(&priv->pdev->dev, skb->data, len,
-						DMA_TO_DEVICE)) - byte_offset;
+	desc->addr = ((unsigned int)dma_map_single(&priv->pdev->dev, skb->data,
+						   skb->len, DMA_TO_DEVICE)) -
+						   byte_offset;
 	/* Make sure the address is written before we give it to HW */
 	wmb();
 	desc->ctl = LTQ_DMA_OWN | LTQ_DMA_SOP | LTQ_DMA_EOP |
-		LTQ_DMA_TX_OFFSET(byte_offset) | (len & LTQ_DMA_SIZE_MASK);
+		LTQ_DMA_TX_OFFSET(byte_offset) | (skb->len & LTQ_DMA_SIZE_MASK);
 	ch->dma.desc++;
 	ch->dma.desc %= LTQ_DESC_NUM;
 	spin_unlock_irqrestore(&priv->lock, flags);
-- 
2.39.5

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

[Florian Fainelli]

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@wp.pl>
> ---
>   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.
-- 
Florian

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

[Aleksander Jan Bajkowski]

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@wp.pl>
>> ---
>>   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

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

[Florian Fainelli]

On 9/23/24 14:08, Aleksander Jan Bajkowski wrote:
> 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@wp.pl>
>>> ---
>>>   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?

There is none right now, but assuming you might add byte queue limits in 
the future, or just re-structure the code, reading from skb->len is 
error prone and is better left avoided, especially since this will 
result in few lines being changed in your case.

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


-- 
Florian