[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210728155340.GQ13220@brightrain.aerifal.cx>
Date: Wed, 28 Jul 2021 11:53:41 -0400
From: Rich Felker <dalias@...c.org>
To: Jasper Hugunin <jasper@...unin.net>
Cc: musl@...ts.openwall.com
Subject: Re: Bug in src/signal/block.c
On Wed, Jul 28, 2021 at 08:00:00AM -0700, Jasper Hugunin wrote:
> Hello,
>
> In musl, as far as I can tell, `_NSIG` is always defined as either 65, or
> 128 (for all three MIPS architectures) at the bottom of
> `${arch}/bits/signal.h`. Meanwhile, in `src/signal/block.c`, there is a
> test `#if ULONG_MAX == 0xffffffff && _NSIG == 129`, which will never
> succeed since _NSIG will be 128 instead of 129. This seems likely to be
> left over from Commit: fix _NSIG and SIGRTMAX on mips
> <https://git.musl-libc.org/cgit/musl/commit/arch?id=7c440977db9444d7e6b1c3dcb1fdf4ee49ca4158>
> ..
>
> I have not demonstrated the bug, I found it by inspection of the source. My
> guess is that this bug causes __block_all_sigs to fail to block high real
> time signals on MIPS. At best, however, this test seems to be dead code.
>
> (I am not subscribed to the mailing list; please cc me directly on any
> responses I need to see.)
> My apologies if I have misunderstood the situation.
Thanks! This is a real bug that will prevent signal blocking from
working correctly on mips, resulting in application code being able to
run in contexts where it is unsafe for that to happen if the
application installs signal handlers on high signal numbers.
Rich
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.
