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] [thread-next>] [day] [month] [year] [list]
Message-ID: <21d7e9970812091808r47e0cf07u8df2a9d2a27b783c@mail.gmail.com>
Date:	Wed, 10 Dec 2008 12:08:13 +1000
From:	"Dave Airlie" <airlied@...il.com>
To:	"Andrew Morton" <akpm@...ux-foundation.org>
Cc:	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Greg KH" <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	"Randy Dunlap" <rdunlap@...otime.net>,
	"Chuck Ebbert" <cebbert@...hat.com>,
	"Domenico Andreoli" <cavokz@...il.com>, alan@...rguk.ukuu.org.uk,
	"Manfred Spraul" <manfred@...orfullife.com>,
	"Clement Calmels" <cboulte@...il.com>,
	"Nadia Derbey" <Nadia.Derbey@...l.net>,
	"Pierre Peiffer" <peifferp@...il.com>
Subject: Re: [patch 021/104] lib/idr.c: fix rcu related race with idr_find

On Wed, Dec 10, 2008 at 12:02 PM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
> On Wed, 10 Dec 2008 11:46:13 +1000 "Dave Airlie" <airlied@...il.com> wrote:
>
>> >>
>> >> On Wed, 10 Dec 2008, Dave Airlie wrote:
>> >>>
>> >>> On Thu, Dec 4, 2008 at 5:49 AM, Greg KH <gregkh@...e.de> wrote:
>> >>> > 2.6.27-stable review patch.  If anyone has any objections, please let us know.
>> >>> >
>> >>> Revert.
>> >>>
>> >>> This caused problems in the F10 kernel with idr, the drm device alloc
>> >>> went all wierd,
>> >>> it might be a drm bug but changing this code triggers it and so it
>> >>> isn't really "stable"
>> >>
>> >> Well, maybe it should be reverted in mainlne too, then?
>> >
>> > It appears idr_replace is broken at least in stable with this patch.
>> >
>> > I'm trying to track down where the problem is (idr_replace doesn't look like
>> > idr_find in a lot of places and I wonder if this has ever been tested.)
>> >
>> (cc-trimmed).
>>
>> Okay I'm not idr expert and maybe what the drm is doing is illegal but
>> it never caused a problem up to now.
>>
>> The drm grabs an idr minor number using a NULL pointer to reserve the
>> number, it then uses idr_replace later
>> to stick a pointer into the reserved number. However this seems to be
>> what is broken, I'm not sure if this is a legal
>> use of idrs but has worked like that for a long time now.
>>
>> I can fix the drm to workaround this, and allocate my pointers before
>> I try to get a minor number, but I'd like to know
>> if my usage is illegal over just overlooked.
>
>
> <greps for a while>
>
> I assume we're talking about drivers/gpu/drm/drm_stub.c:drm_minor_get_id()?
>
> I don't immediately see anything in the idr code which special-cases a
> NULL caller pointer?
>

Actually now that I'm starting to wrap my head around it I think it
might be the fact that I call
idr_get_new_above with 64, then later with 0. I'm not sure the new
code is dealing with that case so
well.

We don't do that in the standard kernel tree yet, so it explains why
nobody's noticed, however the KMS
changes introduce it, and we have those in f10.

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/drm_stub.c;h=5ca132afa4f2e128999e319e44e31ad156e6ab74;hb=drm-next

is the drm_stub.c from drm-next that will trigger the issue.

Again I'm not sure if this is a legal use of idrs.

Dave.

>
--
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