[PATCH] potential array overrun
Zsbán Ambrus
ambrus at math.bme.hu
Tue Jun 12 10:53:10 CEST 2012
On Mon, Jun 11, 2012 at 2:43 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> Below is a patch that fixes a theoretical array overrun. I say theoretical
> because I don't think there is a signal number high enough to trigger this. But
> any ways... the issue is EV_NSIG starts off being 65. Then the array is declared
> as signals [EV_NSIG - 1]; Which means 0-63 would be valid index values. In the
> function ev_feed_signal_event() is a check for signum > EV_NSIG...meaning that
> if signum is 65, it won't return. This gets decremented to 64 and then used as
> an index for a memory write. This is 1 over the top since 63 is the largest
> valid index. I doubt this causes any problems, but a patch below should fix the
> issue.
> diff -urp libev-4.11.orig/ev.c libev-4.11/ev.c
> --- libev-4.11.orig/ev.c 2012-02-04 14:09:52.000000000 -0500
> +++ libev-4.11/ev.c 2012-06-11 07:54:14.719520216 -0400
> @@ -1966,7 +1966,7 @@ ev_feed_signal_event (EV_P_ int signum)
> {
> WL w;
>
> - if (expect_false (signum <= 0 || signum > EV_NSIG))
> + if (expect_false (signum <= 0 || signum >= EV_NSIG))
> return;
>
> --signum;
I think your reasoning is incorrect. While this may seem strange, 64
(equal to EV_NSIG - 1) is typically a valid signal number on Linux
(it's SIGRTMAX, the lowest priority POSIX sigqueue signal). Thus,
libev should support watchers on this signal number.
Ambrus
More information about the libev
mailing list