netdev - Re: [PATCH] Avoid signal race in arpd initialization.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 15 Mar 2015 12:25:15 -0700
From:	Stephen Hemminger <stephen@...workplumber.org>
To:	Tobias Stoeckmann <tobias@...eckmann.org>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] Avoid signal race in arpd initialization.

On Wed, 11 Mar 2015 21:58:45 +0100
Tobias Stoeckmann <tobias@...eckmann.org> wrote:

> Signal handlers in arpd use siglongjmp() to return into main function
> during polls. The environment for the jumps is set after the signal
> handlers are installed. This leaves a small time frame in which an
> uninitialized environment could be used for a siglongjmp() call, leading
> to undefined behavior.
> 
> While at it, define flag variables as sig_atomic_t instead of int.

I understand, but this is such a corner case. And you made several
other changes. Don't think it is worth doing this change.

You would have to signal arpd in the very small window between
the signal setup and the setjmp call.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html