Tobias Stoeckmann wrote:
> On Mon, Apr 22, 2019 at 01:24:13PM -0400, Ted Unangst wrote:
> > ah, good catch. I don't think it's wrong (until it overflows) but needs to
> > be
> > fixed. Needs some more review then. Thanks.
>
> I have added following changes:
>
> - converted 0u to 0 as bluhm poi
Tobias Stoeckmann wrote:
> On Mon, Apr 22, 2019 at 01:24:13PM -0400, Ted Unangst wrote:
> > ah, good catch. I don't think it's wrong (until it overflows) but needs to
> > be
> > fixed. Needs some more review then. Thanks.
>
> I have added following changes:
>
> - converted 0u to 0 as bluhm point
On Sun, Apr 21, 2019 at 08:53:11PM +0200, Alexander Bluhm wrote:
> I wonder whether SIZE_T_MAX would be better than -1. But they seem
> to be equivalent.
I prefer SIZE_T_MAX as well.
> > Index: min_heap.h
> > ===
> > RCS file: /cvs/
On Mon, Apr 22, 2019 at 01:24:13PM -0400, Ted Unangst wrote:
> ah, good catch. I don't think it's wrong (until it overflows) but needs to be
> fixed. Needs some more review then. Thanks.
I have added following changes:
- converted 0u to 0 as bluhm pointed out
- converted -1 to SIZE_MAX whereever
Tobias Stoeckmann wrote:
> Changing n means that at least timeout_correct in event.c must be
> adjusted as well, because it is used as an unsigned:
ah, good catch. I don't think it's wrong (until it overflows) but needs to be
fixed. Needs some more review then. Thanks.
On Sun, Apr 21, 2019 at 08:53:11PM +0200, Alexander Bluhm wrote:
> I wonder whether SIZE_T_MAX would be better than -1. But they seem
> to be equivalent.
I prefer SIZE_T_MAX as well.
> > Index: min_heap.h
> > ===
> > RCS file: /cvs/
On Sat, Apr 20, 2019 at 07:30:50PM -0400, Ted Unangst wrote:
> ok, so back to this. here's a diff which solves this by using appropriate
> size_t types.
There are two 0u which are size_t now. Just use 0.
I wonder whether SIZE_T_MAX would be better than -1. But they seem
to be equivalent.
OK bl
Tobias Stoeckmann wrote:
> I would like to protect min_heap_push against integer overflows,
> which could either be triggered on a 64 bit system with massive
> amounts of RAM (to overflow s->n) or on a 32 bit system with tight
> memory layout (overflowing a * sizeof *p).
>
> Both cases are basical
On Thu, Apr 18, 2019 at 07:49:29PM -0400, Ted Unangst wrote:
> Ted Unangst wrote:
> > (and then reformat to be knf, but after changes that require review.)
>
> mostly mechanical..
OK bluhm@
>
> we'll get to real changes eventually :)
>
>
> Index: min_heap.h
> =
Ted Unangst wrote:
> (and then reformat to be knf, but after changes that require review.)
mostly mechanical..
we'll get to real changes eventually :)
Index: min_heap.h
===
RCS file: /cvs/src/lib/libevent/min_heap.h,v
retrieving re
On Wed, Apr 17, 2019 at 11:34:36AM -0400, Ted Unangst wrote:
> (and then reformat to be knf, but after changes that require review.)
Totally agree here. That will help with further changes to this file!
>
> Index: min_heap.h
> ===
>
On Wed, Apr 17, 2019 at 11:34:36AM -0400, Ted Unangst wrote:
> Theo de Raadt wrote:
> > So the diff presented falls short of what should be done here;
> > insufficient lines deleted.
>
> we're not getting to the fun part yet, but this unfold some complex operations
> to assist human readers.
>
>
Theo de Raadt wrote:
> So the diff presented falls short of what should be done here;
> insufficient lines deleted.
we're not getting to the fun part yet, but this unfold some complex operations
to assist human readers.
-min_child -= min_child == s->n ||
min_heap_elem_greater(s->p[min_ch
Theo de Raadt wrote:
> Reading this min_heap.h code for the first time, I shuddered because it
> reminded me of the exploit mitigation mechanism in openssl which prevent
> heartbleed from being exploitable in the presence of our fine otto
> malloc.
Oops, this is more correct:
Reading this min_h
Reading this min_heap.h code for the first time, I shuddered because it
reminded me of the exploit mitigation mechanism in openssl which prevent
heartbleed from being exploitable in the presence of our fine otto
malloc.
It is a deferred deallocation mechanism *precisely* what prevents bugs
from be
I would like to protect min_heap_push against integer overflows,
which could either be triggered on a 64 bit system with massive
amounts of RAM (to overflow s->n) or on a 32 bit system with tight
memory layout (overflowing a * sizeof *p).
Both cases are basically not possible to be triggered, but
16 matches
Mail list logo
