From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936008AbXG2Utj (ORCPT ); Sun, 29 Jul 2007 16:49:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S934497AbXG2Ut3 (ORCPT ); Sun, 29 Jul 2007 16:49:29 -0400 Received: from static-ip-62-75-166-246.inaddr.intergenia.de ([62.75.166.246]:49205 "EHLO vs166246.vserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755284AbXG2Ut2 (ORCPT ); Sun, 29 Jul 2007 16:49:28 -0400 From: Michael Buesch To: Satyam Sharma Subject: Re: [PATCH] sb1000: prevent a potential NULL pointer dereference in sb1000_dev_ioctl() Date: Sun, 29 Jul 2007 22:49:13 +0200 User-Agent: KMail/1.9.5 Cc: Domen Puncer , Jesper Juhl , Linux Kernel Mailing List , netdev@vger.kernel.org, Steven Hirsch , "David S. Miller" , Stephen Hemminger References: <200707290002.42722.jesper.juhl@gmail.com> <200707292048.20531.mb@bu3sch.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707292249.13957.mb@bu3sch.de> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sunday 29 July 2007 21:09, Satyam Sharma wrote: > Hi Michael, > > > On Sun, 29 Jul 2007, Michael Buesch wrote: > > > On Sunday 29 July 2007 20:34:46 Satyam Sharma wrote: > > > (2) !(dev->flags & IFF_UP) is bogus because the functions of this ioctl > > > can (and should) be allowed even when the interface is not up and running. > > > > Are you _sure_? This function does poke with the device hardware. > > It might return crap or even machinecheck when not initialized. > > Hardware is probably powered down, if not IFF_UP. (I don't know if that's > > the case here, though). > > IFF_UP checks if the _interface_ is up -- the hardware / card could still > be powered up, but the interface down (ifconfing eth0 down or ip link set > eth0 down). Well, that is device/driver dependent and I don't know what's the case for this driver. It's encouraged to shutdown hardware completely (except the WOL parts) when the interface is down. Dunno if this driver does it. But _if_ it does it, it could cause problems to poke with the hardware while down.