linux-kernel - Signal delivery order

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-next>] [day] [month] [year] [list]

Date:	Sat, 14 Mar 2009 17:50:37 +0100
From:	Gábor Melis <mega@...es.hu>
To:	linux-kernel@...r.kernel.org
Subject: Signal delivery order

(Please CC me, I'm not subscribed.)

Attached is a test program that tests the order in which synchronously 
triggered sigsegvs and pthread_kill() generated signals get delivered.

The test program triggers sigsegvs from a thread and tests whether the 
the sigsegv handler is invoked when the sigusr1 handler is already 
running. If that happens it exits with exit code 27. It seems that if 
the signal is sent by pthread_kill() and its signum is lower than that 
of sigsegv then it can be delivered before sigsegv. A normal kill does 
not seem to do this.

I would expect that no asynchronously generated signal (and here I 
include those sent by pthread_kill()) can overtake a sigsegv even if 
its signum is lower.

Reaching this diagnosis led me to an identical looking issue documented 
at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4355769 .

Cheers,
Gabor Melis

PS: tested on x86 linux Debian Lenny, kernel: 2.6.26-1-686, glibc: 
2.7-18

View attachment "signal-delivery-order.c" of type "text/x-csrc" (1961 bytes)