| Message ID | 20240921105801.14578-2-olek2@wp.pl (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: ethernet: lantiq_etop: fix memory disclosure | expand |
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.
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
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 >
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);
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(-)