All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kok, Auke" <auke-jan.h.kok@intel.com>
To: jesper.juhl@gmail.com
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: - eepro100-avoid-potential-null-pointer-deref-in-speedo_init_rx_ring.patch removed from -mm tree
Date: Mon, 01 Oct 2007 13:54:14 -0700	[thread overview]
Message-ID: <47015E76.6080601@intel.com> (raw)
In-Reply-To: <200709290551.l8T5ppNg002621@imap1.linux-foundation.org>

akpm@linux-foundation.org wrote:
> The patch titled
>      eepro100: Avoid potential NULL pointer deref in speedo_init_rx_ring()
> has been removed from the -mm tree.  Its filename was
>      eepro100-avoid-potential-null-pointer-deref-in-speedo_init_rx_ring.patch
> 
> This patch was dropped because an updated version will be merged
> 
> ------------------------------------------------------
> Subject: eepro100: Avoid potential NULL pointer deref in speedo_init_rx_ring()
> From: Jesper Juhl <jesper.juhl@gmail.com>
> 
> In a low memory situation, if you are very unlucky, the speedo_init_rx_ring()
> function may cause a NULL pointer deref.
> 
> The problem is in the case where we can't allocate even a single skb for
> the RX ring.  In this case 'last_rxf' will be NULL when we break out of
> the loop and the line
>     last_rxf->status = cpu_to_le32(0xC0000002);	/* '2' is flag value only. */
> will cause a NULL pointer dereference.
> 
> To fix this properly we need to be return an error from speedo_init_rx_ring()
> and have the caller (speedo_open()) catch and propagate the error, as well as
> undo anything done to setup the device so far.
> 
> This patch adds a check to catch the unlucky case of not even a single skb
> being available and adds code in the caller to catch the error and release the
> device properly.
> 
> For a user who hits this problem, this makes the difference between her device
> not being opened and a kernel crash.  Clearly a non functional NIC if
> preferable to a kernel crash - especially since setting up the device can
> easily be retried later after freeing up some memory; a kernel crash is not as
> easy to recover from.
> 
> The problem was initially spotted by the Coverity checker.
> 
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>


is this actually a problem? everybody should be running e100. I'm surprised to see
a patch for eepro100, just before it gets removed...

Auke

  reply	other threads:[~2007-10-01 20:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-29  5:51 - eepro100-avoid-potential-null-pointer-deref-in-speedo_init_rx_ring.patch removed from -mm tree akpm
2007-10-01 20:54 ` Kok, Auke [this message]
2007-10-02  8:12   ` Jesper Juhl

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=47015E76.6080601@intel.com \
    --to=auke-jan.h.kok@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=jesper.juhl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.