User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160623154057 Steps to reproduce: The libnestegg's main memory allocation function void * halloc(void * ptr, size_t len) from halloc.c (e.g. called by ne_pool_alloc()) does not seem to check for int-overflows when calling the registered mem alloc function pointer: p = allocator(0, len + sizeof_hblock); /* calloc */ if (! ptr) { if (! len) return NULL; p = allocator(0, len + sizeof_hblock); if (! p) return NULL; #ifndef NDEBUG p->magic = HH_MAGIC; #endif hlist_init(&p->children); hlist_init_item(&p->siblings); return p->data; }

Kinetik/Rillian, can you take a look?

It'd be worth reporting this to halloc upstream: https://github.com/apankrat/halloc I believe nestegg's use is safe because the only two calls to halloc with third-party controlled values are sanitized with size limits on the allocation path, see https://github.com/kinetiknz/nestegg/blob/master/src/nestegg.c#L767 and https://github.com/kinetiknz/nestegg/blob/master/src/nestegg.c#L785

(In reply to Matthew Gregan [:kinetik] from comment #2) > It'd be worth reporting this to halloc upstream: > https://github.com/apankrat/halloc Thanks for the link, I will consider it. > I believe nestegg's use is safe because the only two calls to halloc with > third-party controlled values are sanitized with size limits on the > allocation path, see > https://github.com/kinetiknz/nestegg/blob/master/src/nestegg.c#L767 and > https://github.com/kinetiknz/nestegg/blob/master/src/nestegg.c#L785 All right. I assume the ebml element size here https://github.com/kinetiknz/nestegg/blob/master/src/nestegg.c#L986 is not third-party controllable?

(In reply to kernxploit from comment #3) > All right. I assume the ebml element size here > https://github.com/kinetiknz/nestegg/blob/master/src/nestegg.c#L986 is not > third-party controllable? Right, desc->size is sizeof() some nestegg internal struct.

FYI: this was fixed upstream in halloc 1.2.3.