From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 399EEC48BCF for ; Sat, 12 Jun 2021 07:03:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1824F61248 for ; Sat, 12 Jun 2021 07:03:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230504AbhFLHFE (ORCPT ); Sat, 12 Jun 2021 03:05:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:47882 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229584AbhFLHE4 (ORCPT ); Sat, 12 Jun 2021 03:04:56 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9AFF961186; Sat, 12 Jun 2021 07:02:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1623481366; bh=cyYgnn12E0TUjCf1JhTdpZWgTwBzpbkz1bQDyTJlhMM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=yJSnl7XvMM4cnz9idU0uiHyw0U8UmcOhjJUkAVkPeKLRojAjWo41UycxvpWwUJl4x VtiFZyJarVfZjTQmo5Lxd8mWDPWeNA9ZJo9rmuL4nJ90SwBel1si1DcECLZLjExCUm P22i9T5WMTFEHtlgPBvXAp7oENanh6JL9MJ9b+cs= Date: Sat, 12 Jun 2021 09:02:43 +0200 From: Greg KH To: Bernd Edlinger Cc: Andrew Morton , Alexander Viro , Alexey Dobriyan , Oleg Nesterov , Kees Cook , Andy Lutomirski , Will Drewry , Shuah Khan , Christian Brauner , Michal Hocko , Serge Hallyn , James Morris , "Eric W. Biederman" , Charles Haithcock , Suren Baghdasaryan , Yafang Shao , Helge Deller , YiFei Zhu , Adrian Reber , Thomas Gleixner , Jens Axboe , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-kselftest@vger.kernel.org, "stable@vger.kernel.org" Subject: Re: [PATCH v9] exec: Fix dead-lock in de_thread with ptrace_attach Message-ID: References: <20210610143642.e4535dbdc0db0b1bd3ee5367@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 11, 2021 at 05:55:09PM +0200, Bernd Edlinger wrote: > This introduces signal->unsafe_execve_in_progress, > which is used to fix the case when at least one of the > sibling threads is traced, and therefore the trace > process may dead-lock in ptrace_attach, but de_thread > will need to wait for the tracer to continue execution. > > The solution is to detect this situation and allow > ptrace_attach to continue, while de_thread() is still > waiting for traced zombies to be eventually released. > When the current thread changed the ptrace status from > non-traced to traced, we can simply abort the whole > execve and restart it by returning -ERESTARTSYS. > This needs to be done before changing the thread leader, > because the PTRACE_EVENT_EXEC needs to know the old > thread pid. > > Although it is technically after the point of no return, > we just have to reset bprm->point_of_no_return here, > since at this time only the other threads have received > a fatal signal, not the current thread. > > >From the user's point of view the whole execve was > simply delayed until after the ptrace_attach. > > Other threads die quickly since the cred_guard_mutex > is released, but a deadly signal is already pending. > In case the mutex_lock_killable misses the signal, > ->unsafe_execve_in_progress makes sure they release > the mutex immediately and return with -ERESTARTNOINTR. > > This means there is no API change, unlike the previous > version of this patch which was discussed here: > > https://lore.kernel.org/lkml/b6537ae6-31b1-5c50-f32b-8b8332ace882@hotmail.de/ > > See tools/testing/selftests/ptrace/vmaccess.c > for a test case that gets fixed by this change. > > Note that since the test case was originally designed to > test the ptrace_attach returning an error in this situation, > the test expectation needed to be adjusted, to allow the > API to succeed at the first attempt. > > Signed-off-by: Bernd Edlinger > --- > fs/exec.c | 37 +++++++++++++++++++++++++++++-- > fs/proc/base.c | 6 +++++ > include/linux/sched/signal.h | 13 +++++++++++ > kernel/ptrace.c | 9 ++++++++ > kernel/seccomp.c | 12 +++++++--- > tools/testing/selftests/ptrace/vmaccess.c | 25 ++++++++++++++------- > 6 files changed, 89 insertions(+), 13 deletions(-) > This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.