[PATCH 3.16.y-ckt 124/168] net: sun4i-emac: fix memory leak on bad packet

From: Luis Henriques
Date: Mon Dec 15 2014 - 09:39:54 EST


3.16.7-ckt3 -stable review patch. If anyone has any objections, please let me know.

------------------

From: Marc Zyngier <marc.zyngier@xxxxxxx>

commit 2670cc699a66c4cf268cb3e3f6dfc325ec14f224 upstream.

Upon reception of a new frame, the emac driver checks for a number
of error conditions, and flag the packet as "bad" if any of these
are present. It then allocates a skb unconditionally, but only uses
it if the packet is "good". On the error path, the skb is just forgotten,
and the system leaks memory.

The piece of junk I have on my desk seems to encounter such error
frequently enough so that the box goes OOM after a couple of days,
which makes me grumpy.

Fix this by moving the allocation on the "good_packet" path (and
convert it to netdev_alloc_skb while we're at it).

Tested on a random Allwinner A20 board.

Cc: Stefan Roese <sr@xxxxxxx>
Cc: Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx>
Signed-off-by: Marc Zyngier <marc.zyngier@xxxxxxx>
Acked-by: Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
Signed-off-by: Luis Henriques <luis.henriques@xxxxxxxxxxxxx>
---
drivers/net/ethernet/allwinner/sun4i-emac.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c b/drivers/net/ethernet/allwinner/sun4i-emac.c
index d81e7167a8b5..29b9f082475d 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -633,8 +633,10 @@ static void emac_rx(struct net_device *dev)
}

/* Move data from EMAC */
- skb = dev_alloc_skb(rxlen + 4);
- if (good_packet && skb) {
+ if (good_packet) {
+ skb = netdev_alloc_skb(dev, rxlen + 4);
+ if (!skb)
+ continue;
skb_reserve(skb, 2);
rdptr = (u8 *) skb_put(skb, rxlen - 4);

--
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/