linux-kernel - Re: SIGTRAP vs. sys_exit

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]

Message-Id: <20081204005203.7AE1CFC053@magilla.sf.frob.com>
Date:	Tue,  2 Dec 2008 20:47:47 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <onestero@...hat.com>
Cc:	Jan Kiszka <jan.kiszka@...mens.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: SIGTRAP vs. sys_exit_group race

> Roland, what do you think?
> 
> On 10/06, Jan Kiszka wrote:
> >
> > --- a/kernel/signal.c
> > +++ b/kernel/signal.c
> > @@ -1528,10 +1528,11 @@ static void ptrace_stop(int exit_code, i
> >  		spin_unlock_irq(&current->sighand->siglock);
> >  		arch_ptrace_stop(exit_code, info);
> >  		spin_lock_irq(&current->sighand->siglock);
> > -		if (sigkill_pending(current))
> > -			return;
> >  	}
> >
> > +	if (sigkill_pending(current))
> > +		return;
> > +
> 
> Personally, I think this change is good anyway. The tracee shouldn't
> sleep in TASK_TRACED with the pending SIGKILL.

I think this is actually superfluous since TASK_WAKEKILL (2.6.24?).
It won't sleep in TASK_TRACED at all, because of signal_pending_state().

> I think we need further changes. If the thread group group was killed
> by some fatal signal (but not SIGKILL) the tracee will sleep with
> SIGNAL_GROUP_EXIT, this is not nice too. But imho the patch makes
> sense anyway.

When there is no (user-level) SIGKILL and no core dump synchronization, I
think it's desireable for each thread to stop in exit tracing so it can be
fully examined.

I believe the behavior Jan saw is not new, but was always possible in races
depending on when signals got sent.  The SIGTRAP (or PTRACE_EVENT_*)
exit_code might be seen by gdb's wait4 call, but the task can be woken
again by SIGKILL in the next instant and have the death exit_code seen by
the next wait4 call (or not, depending on the race).  Since the The size of
the window where an asynchronous SIGKILL could leave the previous SIGTRAP
(et al) exit_code to be seen by wait4 before seeing the death code might
have changed with the introduction of TASK_WAKEWILL, but it was always
there.

Thanks,
Roland
--
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/