[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 Sep 2023 11:23:08 +0200
From: Joakim Sindholt <opensource@...sha.com>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Add a safe dequeue integrity check for mallocng
On Thu, 14 Sep 2023 13:13:23 +0800, James R T <jamestiotio@...il.com> wrote:
> On Sat, Sep 9, 2023 at 8:48 AM Rich Felker <dalias@...c.org> wrote:
> >
> > This could and should be written with the assert macro, like all the
> > other safety assertions in mallocng, not pulling in stdio and abort.
>
> Understood. I was not able to find an assert with `predict_false` for
> the condition. Should I add one assert function with `predict_false`
> in `include/assert.h` or `src/exit/assert.c` or simply use the regular
> assert?
It's a little confusing but assert() in mallocng is not real assert():
http://git.musl-libc.org/cgit/musl/tree/src/malloc/mallocng/glue.h#n33
The issue is that if memory is under control of an attacker then doing
anything at all, especially running the stdio machinery, is unsafe. To
that end musl uses a_crash() here which expands to a minimal set of
instructions to crash the process:
http://git.musl-libc.org/cgit/musl/tree/arch/x86_64/atomic_arch.h#n106
Furthermore, musl doesn't use any of thosed tagged branch tricks and I
personally doubt it would make any difference.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
