linux-kernel - [PATCH 0/2] ptrace: fix race between ptrace_resume() and wait_task

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]

Message-ID: <20150324185400.GA11826@redhat.com>
Date:	Tue, 24 Mar 2015 19:54:00 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Labath <labath@...gle.com>
Cc:	Josh Stone <jistone@...hat.com>, Pedro Alves <palves@...hat.com>,
	Vince Harron <vharron@...gle.com>, linux-kernel@...r.kernel.org
Subject: [PATCH 0/2] ptrace: fix race between ptrace_resume() and
	wait_task_stopped()

On 03/24, Pavel Labath wrote:
>
> I have tested your patch and I can confirm that the error is gone when
> running a patched kernel.

Great! Thanks a lot for the detailed/clear report and testing.

So I am sending this fix + another patch. 2/2 is "while at it" change,
just because ptrace_detach() can resume the tracee with the new code
too, so it makes sense to add a comment and remove the outdated logic.

> I am still seeing one very rare failure where the SIGUSR does not
> appear to be reported. However, I will need to dig around this a bit
> more to make sure there is no error on our end.

Hmm, perhaps we have (yet) another bug... please let me know if/when
you have more details.

> Now I am thinking about how to work around these bugs, as our code
> will need to run on unpatched kernels as well. As for this
> ptrace/waitpid race, I think I will just refactor the code to make
> wait and ptrace calls on the same thread. This should sidestep the
> race, right?

Yes sure, this will hide the problem.

> Regarding your bug, I am not exactly sure what are the implications.
> Could you briefly describe the situations in which this behavior can
> occur? Am I correct in understanding that this is always a race
> between a SIGKILL and another non-lethal signal? And that the SIGKILL
> will be (eventually) reported?

No, SIGKILL can be never reported. But note that ptrace_stop() does

	set_current_state(TASK_TRACED);

	current->last_siginfo = info;
	current->exit_code = exit_code;

and this is another case when wait_task_stopped() can consume/report this
exit_code even if the tracee won't actually stop because it is killed.

Usually this is not that bad, we can pretend that it was killed after stop.
Still this can confuse the debugger which sends SIGKILL to the stopped tracee.
We need more fatal_signal_pending() checks in ptrace_stop(). And in fact
in get_signal(), I think. The problem is that we need other cleanups here.
But fortunately this problem is minor.

Oleg.

--
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/