[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> > > 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 <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
