Messages in this thread | | | Date | Wed, 5 Apr 2017 14:36:32 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCHv2] ptrace: fix PTRACE_LISTEN race corrupting task->state |
| |
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.
| |