In PT_SEIZED + LISTEN mode STOP/CONT signals cause a wakeup against
__TASK_TRACED. If this races with the ptrace_unfreeze_traced at the end
of a PTRACE_LISTEN, this can wake the task /after/ the check against
__TASK_TRACED, but before the reset of state to TASK_TRACED. This causes
it to instead clobber TASK_WAKING, allowing a subsequent wakeup against
TRACED while the task is still on the rq wake_list, corrupting it.
Signed-off-by: Ben Segall <[email protected]>
---
v2: slight clarification in comments, put the conditional around the
whole wakeup area
Oleg mentioned a preference for making LISTEN unfreeze instead; I have
no preference there, just wanted to make sure that this doesn't get
forgotten entirely.
kernel/ptrace.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 0af928712174..7cc49c3e73af 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -184,11 +184,17 @@ static void ptrace_unfreeze_traced(struct task_struct *task)
WARN_ON(!task->ptrace || task->parent != current);
+ /*
+ * PTRACE_LISTEN can allow ptrace_trap_notify to wake us up
+ * remotely. Recheck state under the lock to close this race.
+ */
spin_lock_irq(&task->sighand->siglock);
- if (__fatal_signal_pending(task))
- wake_up_state(task, __TASK_TRACED);
- else
- task->state = TASK_TRACED;
+ if (task->state == __TASK_TRACED) {
+ if (__fatal_signal_pending(task))
+ wake_up_state(task, __TASK_TRACED);
+ else
+ task->state = TASK_TRACED;
+ }
spin_unlock_irq(&task->sighand->siglock);
}
--
2.12.2.715.g7642488e1d-goog
On Tue, 04 Apr 2017 14:47:34 -0700 [email protected] wrote:
> In PT_SEIZED + LISTEN mode STOP/CONT signals cause a wakeup against
> __TASK_TRACED. If this races with the ptrace_unfreeze_traced at the end
> of a PTRACE_LISTEN, this can wake the task /after/ the check against
> __TASK_TRACED, but before the reset of state to TASK_TRACED. This causes
> it to instead clobber TASK_WAKING, allowing a subsequent wakeup against
> TRACED while the task is still on the rq wake_list, corrupting it.
The changelog doesn't convey the urgency of the fix. To understand
this we'll need to know the user-visible impact of the bug and the
likelihood of someone hitting it.
Also your suggestion regarding which kernel version(s) should be fixed
(and the reasoning) is always valuable.
On 04/04, [email protected] wrote:
>
> v2: slight clarification in comments, put the conditional around the
> whole wakeup area
Acked-by: Oleg Nesterov <[email protected]>
and I think this should go to -stable.
> Oleg mentioned a preference for making LISTEN unfreeze instead; I have
> no preference there,
Yes, but I won't insist if you prefer this more simple fix,
> just wanted to make sure that this doesn't get
> forgotten entirely.
And you are right, I forgot about this bug. Thanks!
Oleg.
> kernel/ptrace.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> index 0af928712174..7cc49c3e73af 100644
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -184,11 +184,17 @@ static void ptrace_unfreeze_traced(struct task_struct *task)
>
> WARN_ON(!task->ptrace || task->parent != current);
>
> + /*
> + * PTRACE_LISTEN can allow ptrace_trap_notify to wake us up
> + * remotely. Recheck state under the lock to close this race.
> + */
> spin_lock_irq(&task->sighand->siglock);
> - if (__fatal_signal_pending(task))
> - wake_up_state(task, __TASK_TRACED);
> - else
> - task->state = TASK_TRACED;
> + if (task->state == __TASK_TRACED) {
> + if (__fatal_signal_pending(task))
> + wake_up_state(task, __TASK_TRACED);
> + else
> + task->state = TASK_TRACED;
> + }
> spin_unlock_irq(&task->sighand->siglock);
> }
>
> --
> 2.12.2.715.g7642488e1d-goog
>
On 04/04, Andrew Morton wrote:
>
> On Tue, 04 Apr 2017 14:47:34 -0700 [email protected] wrote:
>
> > In PT_SEIZED + LISTEN mode STOP/CONT signals cause a wakeup against
> > __TASK_TRACED. If this races with the ptrace_unfreeze_traced at the end
> > of a PTRACE_LISTEN, this can wake the task /after/ the check against
> > __TASK_TRACED, but before the reset of state to TASK_TRACED. This causes
> > it to instead clobber TASK_WAKING, allowing a subsequent wakeup against
> > TRACED while the task is still on the rq wake_list, corrupting it.
>
> The changelog doesn't convey the urgency of the fix. To understand
> this we'll need to know the user-visible impact of the bug and the
> likelihood of someone hitting it.
The kernel can crash or this can lead to other hard-to-debug problems.
In short, "task->state = TASK_TRACED" in ptrace_unfreeze_traced() assumes
that nobody else can wake it up, but PTRACE_LISTEN breaks the contract.
Obviusly it is veru wrong to manipulate task->state if this task is already
running, or WAKING, or it sleeps again.
> Also your suggestion regarding which kernel version(s) should be fixed
> (and the reasoning) is always valuable.
This fixes 9899d11f "ptrace: ensure arch_ptrace/ptrace_request can never
race with SIGKILL"
Oleg.