Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1616392 > unrolled thread

[PATCHv2] ptrace: fix PTRACE_LISTEN race corrupting task->state

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCHv2] ptrace: fix PTRACE_LISTEN race corrupting task->state bsegall@google.com - 2017-04-04 23:50 +0200
    Re: [PATCHv2] ptrace: fix PTRACE_LISTEN race corrupting task->state Andrew Morton <akpm@linux-foundation.org> - 2017-04-05 00:00 +0200
      Re: [PATCHv2] ptrace: fix PTRACE_LISTEN race corrupting task->state Oleg Nesterov <oleg@redhat.com> - 2017-04-05 14:40 +0200
    Re: [PATCHv2] ptrace: fix PTRACE_LISTEN race corrupting task->state Oleg Nesterov <oleg@redhat.com> - 2017-04-05 14:40 +0200

#1616392 — [PATCHv2] ptrace: fix PTRACE_LISTEN race corrupting task->state

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 <bsegall@google.com>
---

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

[toc] | [next] | [standalone]

#1616398

On Tue, 04 Apr 2017 14:47:34 -0700 bsegall@google.com 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.

[toc] | [prev] | [next] | [standalone]

#1616887

On 04/04, Andrew Morton wrote:
>
> On Tue, 04 Apr 2017 14:47:34 -0700 bsegall@google.com 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.

[toc] | [prev] | [next] | [standalone]

#1616895

On 04/04, bsegall@google.com wrote:
>
> v2: slight clarification in comments, put the conditional around the
> whole wakeup area

Acked-by: Oleg Nesterov <oleg@redhat.com>

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
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web