From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A389F31353E for ; Mon, 10 Nov 2025 14:47:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762786072; cv=none; b=JJACbuer55b9j8lRdWZ8N5P433IIxycJpKgTdQpdZ6AZgpdO8SlXENF3HKP3Yvl6ljaJ4LVTJDGJhE8/E5rRoIZt5qx2FytME+U50bCrhiDUpynfEld6FXYwBxdpnZj5q7ngm202r7e95910Mg0Iy4hccU9taNprHTIfDy+tLLA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762786072; c=relaxed/simple; bh=dgdLTnC9OagC7TcCvigEKRgst8vGqHZqM0+amuk2YAo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=K9aeYYkzBsbLrQhi0/TPAHIkylzSLgiEty1Pyb88ewYAz3HXJq0WF9Y2Op9wZDGj+P3/7zKZPyI1uBUcq604aj95oC8UGPsYnnepXoO+tuu8zmm50VYKswz42IYe+CABG938pHhsJSV/Y7ymYAzHLEKtPtXJMmnvmvG9xU6wJGs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Xz60gTbZ; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Xz60gTbZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1762786069; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uIeb35oP9Vs/R5h7VhglPZyEdkMXH/upLLEanGBOeTA=; b=Xz60gTbZggctvqMyRadIH86E6OfzXHAsxNMqqOU12nBpvcWc6S9JiRDMGTh7lHuhWHLHhL JxpNq7hVIKTmn5n38THhHP3C7D0aNhW3KRSkji32ICuFPUKXN4lN1WgevmtMeDICw2DETm zMBNt6EfEdBzKBGDQQa7Mdy8JoFnfmg= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-502-b2a0058xO8GOujbU21T91g-1; Mon, 10 Nov 2025 09:47:36 -0500 X-MC-Unique: b2a0058xO8GOujbU21T91g-1 X-Mimecast-MFC-AGG-ID: b2a0058xO8GOujbU21T91g_1762786050 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 49CC218002CB; Mon, 10 Nov 2025 14:47:28 +0000 (UTC) Received: from fedora (unknown [10.44.33.158]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with SMTP id 787811800451; Mon, 10 Nov 2025 14:47:08 +0000 (UTC) Received: by fedora (nbSMTP-1.00) for uid 1000 oleg@redhat.com; Mon, 10 Nov 2025 15:47:27 +0100 (CET) Date: Mon, 10 Nov 2025 15:47:06 +0100 From: Oleg Nesterov To: Bernd Edlinger Cc: Linus Torvalds , Dmitry Levin , Alexander Viro , Alexey Dobriyan , Kees Cook , Andy Lutomirski , Will Drewry , Christian Brauner , Andrew Morton , Michal Hocko , Serge Hallyn , James Morris , Randy Dunlap , Suren Baghdasaryan , Yafang Shao , Helge Deller , "Eric W. Biederman" , Adrian Reber , Thomas Gleixner , Jens Axboe , Alexei Starovoitov , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, tiozhang , Luis Chamberlain , "Paulo Alcantara (SUSE)" , Sergey Senozhatsky , Frederic Weisbecker , YueHaibing , Paul Moore , Aleksa Sarai , Stefan Roesch , Chao Yu , xu xin , Jeff Layton , Jan Kara , David Hildenbrand , Dave Chinner , Shuah Khan , Elena Reshetova , David Windsor , Mateusz Guzik , Ard Biesheuvel , "Joel Fernandes (Google)" , "Matthew Wilcox (Oracle)" , Hans Liljestrand , Penglei Jiang , Lorenzo Stoakes , Adrian Ratiu , Ingo Molnar , "Peter Zijlstra (Intel)" , Cyrill Gorcunov , Eric Dumazet Subject: Re: [RFC PATCH 0/3] mt-exec: fix deadlock with ptrace_attach() Message-ID: References: Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Hi Bernd, On 11/10, Bernd Edlinger wrote: > > When the debugger wants to attach the de_thread the debug-user access rights are > checked against the current user and additionally against the new user credentials. > This I did by quickly switching the user credenitals to the next user and back again, > under the cred_guard_mutex, which should make that safe. Let me repeat, I can't really comment this part, I don't know if it is actually safe. But the very fact your patch changes ->mm and ->cred of the execing task in ptrace_attach() makes me worry... At least I think you should update or remove this comment in begin_new_exec: /* * cred_guard_mutex must be held at least to this point to prevent * ptrace_attach() from altering our determination of the task's * credentials; any time after this it may be unlocked. */ security_bprm_committed_creds(bprm); > So at this time I have only one request for you. > Could you please try out how the test case in my patch behaves with your fix? The new TEST(attach2) added by your patch fails as expected, see 3/3. 128 static long thread2_tid; 129 static void *thread2(void *arg) 130 { 131 thread2_tid = syscall(__NR_gettid); 132 sleep(2); 133 execlp("false", "false", NULL); 134 return NULL; 135 } 136 137 TEST(attach2) 138 { 139 int s, k, pid = fork(); 140 141 if (!pid) { 142 pthread_t pt; 143 144 pthread_create(&pt, NULL, thread2, NULL); 145 pthread_join(pt, NULL); 146 return; 147 } 148 149 sleep(1); 150 k = ptrace(PTRACE_ATTACH, pid, 0L, 0L); 151 ASSERT_EQ(k, 0); 152 k = waitpid(-1, &s, 0); 153 ASSERT_EQ(k, pid); 154 ASSERT_EQ(WIFSTOPPED(s), 1); 155 ASSERT_EQ(WSTOPSIG(s), SIGSTOP); 156 k = ptrace(PTRACE_SETOPTIONS, pid, 0L, PTRACE_O_TRACEEXIT); 157 ASSERT_EQ(k, 0); 158 thread2_tid = ptrace(PTRACE_PEEKDATA, pid, &thread2_tid, 0L); 159 ASSERT_NE(thread2_tid, -1); 160 ASSERT_NE(thread2_tid, 0); 161 ASSERT_NE(thread2_tid, pid); 162 k = waitpid(-1, &s, WNOHANG); 163 ASSERT_EQ(k, 0); 164 sleep(2); 165 /* deadlock may happen here */ 166 k = ptrace(PTRACE_ATTACH, thread2_tid, 0L, 0L); PTRACE_ATTACH fails. thread2() kills the old leader, takes it pid, execlp() succeeds. Oleg.