From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933123AbdDEMgs (ORCPT <rfc822;w@1wt.eu>);
        Wed, 5 Apr 2017 08:36:48 -0400
Received: from mx1.redhat.com ([209.132.183.28]:51224 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S933095AbdDEMgf (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 5 Apr 2017 08:36:35 -0400
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2397D76E6
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=oleg@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2397D76E6
Date: Wed, 5 Apr 2017 14:36:32 +0200
From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: bsegall@google.com, linux-kernel@vger.kernel.org,
        Roland McGrath <roland@hack.frob.com>, Tejun Heo <tj@kernel.org>
Subject: Re: [PATCHv2] ptrace: fix PTRACE_LISTEN race corrupting task->state
Message-ID: <20170405123632.GB3824@redhat.com>
References: <xm2637f7js85.fsf@bsegall-linux.mtv.corp.google.com>
 <20170224163611.GA24902@redhat.com>
 <xm26y3vfhmkp.fsf_-_@bsegall-linux.mtv.corp.google.com>
 <20170404145310.1de5e75f0bd916aef812e136@linux-foundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170404145310.1de5e75f0bd916aef812e136@linux-foundation.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 05 Apr 2017 12:36:35 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.