linux-kernel - Re: [patch 3/4 -mm] flex_array: poison free elements

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]

Date:	Mon, 24 Aug 2009 15:44:04 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 3/4 -mm] flex_array: poison free elements

On Mon, 24 Aug 2009, Dave Hansen wrote:

> On Mon, 2009-08-24 at 13:41 -0700, David Rientjes wrote:
> > On the other hand, I'd have no problem trying to eliminate 
> > fa->total_nr_elements (since we already have fa->element_size) since we 
> > can calculate it in real-time; the only problem is being able to 
> > distinguish when the elements are being stored in struct flex_array vs. 
> > being stored in struct flex_array_part.
> 
> Yeah, that's the only reason it's there: to determine if we're using the
> compact form or not.  We could probably find another place to store
> that, or just store a flag telling whether we're using that form or not.
> We couldn't do the bounds-checking, but I'm OK with that.
> 

I'm starting to think that maybe an `unsigned int flags' is eventually 
going to need to be added anyway: one reason is to serve this purpose of 
identifying arrays that are stored in the base structure.  Another 
possible reason is to identify flex arrays that want the poison behavior 
to identify use-uninitialized and use-after-free and would be passed such 
as flex_array_alloc(size, total, FLEX_ARRAY_POISON, gfp) to isolate arrays 
that may, as you said, store elements of types other than void * or those 
significantly small enough that they would collide with the poison values 
at a higher probability.
--
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/