linux-kernel - Re: avr32: handle

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

Date:	Mon, 08 Aug 2011 11:25:49 +0100
From:	Matt Fleming <matt@...sole-pimps.org>
To:	Håvard Skinnemoen <hskinnemoen@...il.com>
Cc:	Hans-Christian Egtvedt <egtvedt@...fundet.no>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: avr32: handle_signal() bug?

On Sun, 2011-08-07 at 10:20 -0700, Håvard Skinnemoen wrote:
> Hi Matt,
> 
> On Wed, Aug 3, 2011 at 2:04 AM, Matt Fleming <matt@...sole-pimps.org> wrote:
> > That doesn't look correct to me. Now, if we were unsuccessful in setting
> > up a signal frame, say, ret == -EFAULT, do we really want to block the
> > signal or any of the signals in the handler mask?
> 
> I'm assuming this is a rhetorical question :-)

Sort of. I phrased it as a question so that someone could point out
whether my analysis was correct or not ;-)

> Looks good to me. I'm not sure how to test it though...I can try to
> build a kernel, run it on my board and see if it explodes, but I
> suspect this bug is a lot more subtle than that.

I suspect the best test would be one that makes use of SA_NODEFER.
Something like this,

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

void handler(int signum)
{
	sigset_t mask;

	sigprocmask(SIG_BLOCK, NULL, &mask);
	printf("SIGUSR2: %s\n",
	       sigismember(&mask, SIGUSR2) ? "blocked" : "not blocked");
	printf("SIGTERM: %s\n",
	       sigismember(&mask, SIGTERM) ? "blocked" : "not blocked");
}

int main(int argc, char **argv)
{
	pid_t pid;

	pid = fork();
	if (pid == -1) {
		perror("fork");
		exit(EXIT_FAILURE);
	} else if (!pid) {
		struct sigaction act;

		memset(&act, 0, sizeof(act));
		act.sa_handler = handler;
		act.sa_flags = SA_NODEFER;

		sigaddset(&act.sa_mask, SIGUSR2);
		sigaddset(&act.sa_mask, SIGTERM);

		sigaction(SIGUSR1, &act, NULL);

		pause();
	} else {
		int status;

		sleep(3);
		kill(pid, SIGUSR1);
		waitpid(pid, &status, 0);
	}

	return 0;
}

Without the patch applied I would expect this testcase to run the signal
handler without SIGUSR2 or SIGTERM blocked. With the patch I'd hope you
would see the following,

[matt@...eming-mobl1 signal-tests]$ ./nodefer
SIGUSR2: blocked
SIGTERM: blocked

-- 
Matt Fleming, Intel Open Source Technology Center

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/