mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Eric Sesterhenn <snakebyte@gmx.de>
Cc: linux-kernel@vger.kernel.org, jgarzik@pobox.com
Subject: Memory corruption in 8390.c ? (was Re: Possible leaks in network drivers)
Date: Wed, 21 Jun 2006 18:13:02 +0100	[thread overview]
Message-ID: <1150909982.15275.100.camel@localhost.localdomain> (raw)
In-Reply-To: <1150907317.8320.0.camel@alice>

Ar Mer, 2006-06-21 am 18:28 +0200, ysgrifennodd Eric Sesterhenn:
> of the driver. Where we call skb=skb_padto(skb, ETH_ZLEN),
> and dont free the skb later when something goes wrong.

skb_padto() returns either a new buffer or the existing one depending
upon the space situation. If it returns a new buffer then it frees the
old one.

The sequence is

dev_queue_xmit(skb)
	->hard_start_xmit(dev, skb)
	if (0)
		free skb
	return

Which I think means that the error path for a short packet would double
free the skb buffer and leak nskb.


So these drivers should indeed be checking their status before they
clone the buffer. At the point they do an skb_padto they must not fail
if the skb_padto succeeds.

In the case of 8390.c this was broken in 2.6.9 when the efficient 8390
padding code was replaced by something slower and it turns out broken -
although nobody realised that last bit until the checker came along.

See: http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-02/4480.html

Although reverting the change was proposed it was not actually done.


The following should do the trick:

Signed-off-by: Alan Cox <alan@redhat.com>

--- drivers/net/8390.c~	2006-06-21 17:41:12.006145536 +0100
+++ drivers/net/8390.c	2006-06-21 17:41:12.007145384 +0100
@@ -275,12 +275,14 @@
 	struct ei_device *ei_local = (struct ei_device *) netdev_priv(dev);
 	int send_length = skb->len, output_page;
 	unsigned long flags;
+	char buf[64];
+	char *data = skb->data;
 
 	if (skb->len < ETH_ZLEN) {
-		skb = skb_padto(skb, ETH_ZLEN);
-		if (skb == NULL)
-			return 0;
+		memset(buf, 0, ETH_ZLEN);	/* more efficient than doing just the needed bits */
+		memcpy(buf, data, ETH_ZLEN);
 		send_length = ETH_ZLEN;
+		data = buf;
 	}
 
 	/* Mask interrupts from the ethercard. 
@@ -347,7 +349,7 @@
 	 * trigger the send later, upon receiving a Tx done interrupt.
 	 */
 	 
-	ei_block_output(dev, send_length, skb->data, output_page);
+	ei_block_output(dev, send_length, data, output_page);
 		
 	if (! ei_local->txing) 
 	{




  parent reply	other threads:[~2006-06-21 16:58 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-21 16:28 Possible leaks in network drivers Eric Sesterhenn
2006-06-21 17:05 ` Randy.Dunlap
2006-06-21 17:13 ` Alan Cox [this message]
2006-06-21 17:23   ` Memory corruption in 8390.c ? Ben Pfaff
2006-06-21 17:54     ` Alan Cox
2006-06-21 18:03       ` Ben Pfaff
2006-06-21 20:50         ` Alan Cox
2006-06-21 17:59     ` PATCH: Re: Memory corruption in 8390.c ? (and hp100 xirc2ps smc9194 ....) Alan Cox
2006-06-21 19:00       ` Olivier Galibert
2006-06-21 17:50   ` Possible leaks in network drivers Eric Sesterhenn
2006-06-22  1:41     ` Herbert Xu
2006-06-22  0:55   ` Memory corruption in 8390.c ? (was Re: Possible leaks in network drivers) Herbert Xu
2006-06-22  2:30     ` Herbert Xu
2006-06-22  8:22       ` Jeff Garzik
2006-06-22  8:29         ` Herbert Xu
2006-06-22  8:57           ` Jeff Garzik
2006-06-22  9:02             ` Herbert Xu
2006-06-22  9:12               ` Herbert Xu
2006-06-22  8:26       ` Memory corruption in 8390.c ? David Miller
2006-06-22  8:30         ` Herbert Xu
2006-06-22  8:34           ` David Miller
2006-06-22 11:34             ` Alan Cox
2006-06-22 11:29               ` Herbert Xu
2006-06-22 13:25                 ` Alan Cox
2006-06-23  3:32                   ` Jeff Garzik
2006-06-22 11:33               ` Arjan van de Ven
2006-06-22 12:00                 ` Erik Mouw
2006-06-22 13:10                 ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1150909982.15275.100.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=snakebyte@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome