lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 31 Mar 2011 19:15:38 +0200
From:	Florian Mickler <florian@...kler.org>
To:	"Justin P. Mattock" <justinmattock@...il.com>
Cc:	linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
	Manjunatha Halli <manjunatha_halli@...com>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [BUG] NULL pointer dereference in dev_get_drvdata

On Thu, 31 Mar 2011 08:41:53 -0700
"Justin P. Mattock" <justinmattock@...il.com> wrote:

> >
> two drivers calling the same function(sounds bad!) this would be a race 
> condition right?

No. A race is about data. While many races involve the same function
beeing called multiple times in parallel, it is not necessary. It may
well be two seperate functions accessing the same data. 

Also you can of course have two functions doing the same thing to
different data. Just look at dev_get_drvdata... 

void *dev_get_drvdata(const struct device *dev)
{
        if (dev && dev->p)
                return dev->p->driver_data;
        return NULL;
}


it just returns a memory address relativ to the *dev pointer given to
it.  So if you call it multiple times in parallel with different *dev
pointers, nothing happens. 

In fact, dev_get_drvdata is read only, so it alone can never cause any
race. (Except in some obscure on-stack dma setups which are broken,
uncommen and avoided)

For dev_get_drvdata to be part of a race, you would have (for example)
something setting dev->p to NULL in parallel. 

That way, if that something gets to execute between the 

	if (dev && dev->p) 

line and the 
		return dev->p->driver_data;

then, that would be bad, because dev_get_drvdata would have already
decided that that if is true.... 

 
> As for this message I will keep my eye out for anything in this area and 
> report it to you guys.

But please if you put up fotos, try to have a pixel:character quota of
more then 3 ... and also remember, the stacktrace is
almost always the important part of the warning.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ