Re: malloc cleanup and small optimization (step 2)

On 30 December 2017 at 06:44, Otto Moerbeek wrote: > On Sat, Dec 30, 2017 at 06:53:44AM +, kshe wrote: > >> Hi, >> >> Looking at this diff and the previous one, I found some more possible >> cleanups for malloc.c (the patch below is to be applied after both of >> them, even if

Re: malloc.c: better double free check

> In the end all double frees still will be caught by the actual free > code, just with a delay. The delayed free buffer double free check is > just a way of catching it as soon as possible to make debugging > easier. That's the reason the originla code could just do the check > on the slot being

Re: malloc.c: better double free check

On Sat, 2017-09-23 at 09:32 +0200, Otto Moerbeek wrote: > On Fri, Sep 22, 2017 at 04:35:39PM -0400, Daniel Micay wrote: > > > A linear search works well for the current small quarantine (16) but > > won't work > > well if you ever want to have a larger / configurable quara

Re: malloc.c: better double free check

A linear search works well for the current small quarantine (16) but won't work well if you ever want to have a larger / configurable quarantine size. It would also be nice to make this fast enough to enable by default. We (CopperheadOS) use an open addressed hash table for this based on the

Re: random malloc junk

On Tue, 2016-09-13 at 13:27 +0200, Otto Moerbeek wrote: > On Thu, Sep 08, 2016 at 06:42:33PM -0400, Daniel Micay wrote: > > > A bit off-topic: 'J' enables junk-on-init which is for debugging, > > but it > > also currently has security improvements for large allocatio

Re: random malloc junk

A nice security property of 0xdf filling is that a use-after-free of a pointer is guaranteed to fault in a typical environment since it ends up pointing outside userspace (I assume that's the case on OpenBSD). A heap spray could potentially allow exploiting a random pointer. Perhaps it would be

Re: random malloc junk

> BTW, we should revisit canaries and work further on moving them > closer to requested size. There's a chance this diff wil complicate > that. Can switch the canary code to memcpy/memcmp (to handle unaligned canaries) and could then use the last byte as an index to the start of the canary. For

Re: random malloc junk

On Wed, 2016-09-07 at 18:29 -0400, Ted Unangst wrote: > Instead of always using a fixed byte pattern, I think malloc should > use a > random pattern. Now, this sometimes means it's harder to identify > exactly > what's used after free, so we should provide a means to get the old > 0xdf > pattern

malloc: add full delayed chunk double-free detection

This uses a hash table to maintain a set of delayed allocations, allowing full and efficient double-free detection. The current code can only catch it when the two pointers being swapped are equal, so double-frees that could be caught are missed. A naive loop over every delayed chunk would work

Re: malloc: fix setting errno on out-of-memory

Sorry, my mail client was being stupid. Lets try again in good old mutt: diff --git a/stdlib/malloc.c b/stdlib/malloc.c index bc328d2..aa6f0a3 100644 --- a/stdlib/malloc.c +++ b/stdlib/malloc.c @@ -1224,8 +1224,9 @@ malloc(size_t size) r = omalloc(d, size, 0, CALLER); d->active--;

malloc: fix setting errno on out-of-memory

The ENOMEM errno wasn't being set in some code paths where it was gated behind mopts.malloc_xmalloc: diff --git a/stdlib/malloc.c b/stdlib/malloc.c index bc328d2..aa6f0a3 100644 --- a/stdlib/malloc.c +++ b/stdlib/malloc.c @@ -1224,8 +1224,9 @@ malloc(size_t size) r = omalloc(d, size, 0,

Re: multi-pool malloc wip diff

> - Curently fixed at 4 pools with a fixed thread -> pool mapping. > - All pools are always initialized, even for single threaded programs, > where >   only one pool is used. > - Especially realloc gets quite a bit uglier. > - I'm pondering storing the thread -> pool mapping in the thread >  

Re: refine canaries

On Wed, 2015-12-09 at 07:47 -0500, Ted Unangst wrote: > This is a kind of two steps forward, one step back diff. > > I would like for the canary to be placed directly adjacent to the end > of the > user specified size. No slack. To accomplish this, we record the > original size > of the

Re: malloc canaries and validation

It would be great to land this simple initial implementation and move from there. I have ideas on how to make these features better but I'm wary of doing a lot of work out-of-tree. If it lands in some form, that would go a long way to encouraging further work on it. I basically just don't want to

Re: malloc canaries and validation

On Sun, 2015-12-06 at 17:10 -0700, Theo de Raadt wrote: > Kept out of circulation?  It sounds like it would be incredibly > expensive data-structure wise for the kernel to even attempt such a > gaurantee.. I was just expecting it to be a FIFO ring buffer. It would have a limit on the number of

Re: malloc canaries and validation

It would also be interesting to try out a more aggressive form of freeunmap for 64-bit where the allocations are purged with MADV_FREE and then the virtual memory is kept out of circulation with a similar FIFO queue approach. Could potentially do it by default when malloc hints are enabled, so it

Re: enhanced use-after-free detection for malloc v2

far away the UAF is from the free call since one other free is all that's needed to lose reliable detection. It might work better with a FIFO ring buffer rather than the current fully randomized array (perhaps a mix? dunno). > On Sun, Nov 01, 2015

Re: enhanced use-after-free detection for malloc v2

(without mangling it this time...) diff --git a/stdlib/malloc.c b/stdlib/malloc.c index 424dd77..c408594 100644 --- a/stdlib/malloc.c +++ b/stdlib/malloc.c @@ -182,6 +182,7 @@ struct malloc_readonly { int malloc_freeunmap; /* mprotect free pages PROT_NONE? */ int

Re: enhanced use-after-free detection for malloc v2

On 26/10/15 04:19 PM, Daniel Micay wrote: > This is an improved revision of my earlier patch. > > It now validates the junk data in the delayed_chunks array in an atexit > handler > too, rather than just when allocations are swapped out. > > It will now catch this simple

enhanced use-after-free detection for malloc v2

This is an improved revision of my earlier patch. It now validates the junk data in the delayed_chunks array in an atexit handler too, rather than just when allocations are swapped out. It will now catch this simple UAF 100% of the time: #include #include int main(void) { size_t i; char

Re: support for malloc allocation canaries

On 25/10/15 06:20 PM, Ted Unangst wrote: > Daniel Micay wrote: >> This patch adds an opt-in malloc configuration option placing canaries after >> small allocations to detect heap overflows on free(...). It's intended to be >> used alongside guard pages for large allocations. S

Re: enhanced use-after-free detection for malloc

Er, here it is without the screwed up whitespace (whoops): diff --git a/stdlib/malloc.c b/stdlib/malloc.c index 424dd77..7c33a7a 100644 --- a/stdlib/malloc.c +++ b/stdlib/malloc.c @@ -182,6 +182,7 @@ struct malloc_readonly { int malloc_freeunmap; /* mprotect free pages

Re: support for malloc allocation canaries

On 23/10/15 07:22 AM, Janne Johansson wrote: > With this patch on -current and > ln -sf CJ /etc/malloc.conf > a lot of things stopped working, like "man ls" and "tmux". > With only C or only J, the system seems to work ok, but with both it > doesn't. > Will check the resulting core files. > ntpd

enhanced use-after-free detection for malloc

This patch adds a form of use-after-free detection based on validating that the junk data is still in place when swapping out an allocation from the delayed chunk cache. It will probably nearly double the cost of the junk free feature that's enabled by default since it needs to do a whole extra

support for malloc allocation canaries

Hi, This patch adds an opt-in malloc configuration option placing canaries after small allocations to detect heap overflows on free(...). It's intended to be used alongside guard pages for large allocations. Since it's essentially adding extra padding to all small allocations, a small heap