linux-kernel - Re: [PATCH 1/6] idr: fix top layer handling

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: <20130212171049.GA7348@htj.dyndns.org>
Date:	Tue, 12 Feb 2013 09:10:49 -0800
From:	Tejun Heo <tj@...nel.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org,
	Rusty Russell <rusty@...tcorp.com.au>, stable@...r.kernel.org
Subject: Re: [PATCH 1/6] idr: fix top layer handling

Hey, Andrew.

On Mon, Feb 11, 2013 at 03:39:55PM -0800, Andrew Morton wrote:
> This doesn't apply happily to 3.7, so Greg will be needing a redone
> version when the time arrives.
> 
> But does it really need backporting?  Is anyone likely to hit this in
> practice?

For most cases, probably not.  IDR_BITS being 5 and 6 on 32 and 64bit
respectively, the only misbehaving bit is bit 30, so unless ID goes
over 1G, which should be close to non-existent if the IDs are being
allocated from zero, it shouldn't be a problem; however, we do have
users where IDR is used to allocate cyclic IDs.  They maintain and
progress the last allocated ID so that IDs don't get recycled without
wrapping around.  I have no idea whether any of them would be
allocating IDs fast enough to go over 1G limit in any reasonable
amount of time or whether there are such ID allocations which can be
exploited from userland without root priviliedges, in which case it
would probably directly lead to oops.

So, to sum up, at least I can't rule out the issue happening or being
exploited in the wild with older kernels.  It isn't too likely to
happen naturally but if there's a userland exploitable cyclic
alloction, going over 1G wouldn't be too difficult.

> Also, I assume you have some sort of IDR test harness over there.  Is
> it something we can get into the tree in some fashion to help with
> ongoing maintenance?

Right now, it's just a messy test module with ad-hoc loops and manual
alloc/frees with a lot of printks sprinkled everywhere, so I'm afraid
it wouldn't be suitable for any form of automated test.  It sure would
be great to have a testing harness for this tho.

Thanks.

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