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: <20110126130407.GD3070@secunet.com>
Date:	Wed, 26 Jan 2011 14:04:07 +0100
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
Cc:	Eric Paris <eparis@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: flex_array related problems on selinux policy loading

On Fri, Jan 21, 2011 at 07:57:35AM -0800, Dave Hansen wrote:
> 
> My suggestion would be to simply make sure that the code handles 0-sized
> objects and 0-length arrays OK, and do it in two separate patches.  The
> ZERO_SIZE_PTR can't be used for both because you need to know which
> situation you were in and you need different behavior (like in
> flex_array_put()).
> 
> Frankly, I like the idea of just allocating a 'struct flex_array' in any
> case, and just teaching the code to handle element_size=0 and
> nr_elements=0.  That way, if you have bugs in the code that does things
> like flex_array_alloc(elem_size=0, len=5, ...) and then
> flex_array_get(fa, index=99), you have the potential to detect and
> report the bugs.  The only way to do that is to remember what you set
> the length as.  
> 

Another thing came to my mind. An atempt to do a zero size allocation
always succeed on kmalloc. If we want to allocate our metadata even in
this case, we should be aware that this allocation _can_ fail. So
flex_array_alloc would not show the same behaviour as kmalloc on zero
size allocations. As most potential flex_array users convert their code
from kmalloc, the behaviour of flex_array_alloc should be the same as of
kmalloc. Showing a different behaviour here will produce pitfalls for
potential new users. Also, to tell a user that we can not allocate memory
for him, if the wants to allocate 0 byte (nothing) is quite odd. This
user could easily continue processing, even if we can not allocate our
metadata in this moment.

>From this point of view, I'd tend to not allocating anything. Instead we
could return two newly defined pointers, e.g. FLEX_ARRAY_ZERO_SIZE and
FLEX_ARRAY_ZERO_ELEMENTS to catch if either element_size or
total_nr_elements is zero.

The downside of this is of course, that we can't catch the bugs you
mentioned above.

Steffen

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