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:32:07 -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 2/4 -mm] flex_array: add flex_array_clear function

On Mon, 24 Aug 2009, Dave Hansen wrote:

> OK, just to make sure I'm understanding what you are saying.  If we
> haven't allocated the 'part' of a given element, then this code is
> bogus.  flex_array_get() will return NULL, and we have nothing to
> memset().  We effectively need flex_array_get()'s behavior, but we also
> need to ensure that there is space for the element allocated if it
> wasn't before flex_array_clear() is called.  Right?
> 

Yes, that would be the only way to eventually be able to distinguish 
between use-uninitialized and use-after-free; I don't know whether that 
information is helpful to the person developing code that is using flex 
array or not, but it costs nothing to do other than adding another poison 
value.  Since flex_array_get() will never allocate parts, we can't use it 
as-is since it returns NULL for both getting beyond the array upper bound 
and for an unallocated part.  If it returned an ERR_PTR() that would 
distinguish between the two, we could do a variation of what you suggested 
and then check the return value, yet we still have the same restriction of 
never increasing FLEX_ARRAY_PART_SIZE beyond PAGE_SIZE if we're to avoid 
wasted memory space (static char zero_part[FLEX_ARRAY_PART_SIZE]) to 
simply refactor the code with no other improvement.
--
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