From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f195.google.com (mail-pl1-f195.google.com [209.85.214.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9C7D726CE23 for ; Tue, 6 Jan 2026 07:07:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767683257; cv=none; b=ps8lEZf7GPBWMGeLAmcm0pO/+OvsjzudQT0ZsmvunWkiX+SlZdRz0jQYkzfMCzPg/vbV0Q9zYu+j5SCIOustz01pel9Rc7rlCnyH85P1pTzsjbFKnxhmASLATZfYJDDSZgJ7XgIX+MO1qig3I2iK2tDxt/73/wkvKJsgJT5aZ60= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767683257; c=relaxed/simple; bh=5tLtVNZE8m3bMzeDW7Cr+IG7hvzsOWIs9d7DFHZ3N6M=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=tfFamkl2wCoTI2dqhFjmLmOD+bc8n05AnNNEIuy+ZlHI2U25kNIBpewAY2ZAxrAGcLqRzsPXxVjB06rDz5e3pNvYWoDT2pfDLZMqKBMgFO/TYXdgWJKqpWEaCJNxPsoFZAXzr+hEGovaF7p5beMHt9YAw+NndMOpUUZlT17fm7g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jdILUZUB; arc=none smtp.client-ip=209.85.214.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jdILUZUB" Received: by mail-pl1-f195.google.com with SMTP id d9443c01a7336-2a12ed4d205so6713945ad.0 for ; Mon, 05 Jan 2026 23:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767683255; x=1768288055; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Tsuh7/jn2jrlTYfOWGAUThNB0B3UU7lnuVu7OzAU18M=; b=jdILUZUB5+6+nxarmceb6gEiD9L+WTno9P48qQg0svYjsQYM9T++fgW3v1WylIIGWk 4CjZbNu658hFG704eszALHcNOgyDo+Xpddw/1SW9+uZITidJPKDexklOWrLSmE71oKum vI1tPZT39sJf8CXZpu047cjNXFPVCJMDOwAgXBz1NVZ7gte7TWLbA8QY9U4Omac7iPX1 4mKbDKDXZcsAFSnt3nZg3Yn40Zxwt3yBHMrQdZU1uDj+VkVucwre9V0w0Qsd2S27rEBu MKQWSMagFhQpOwFoom6uH8TpBirBAHScW8QA+sEoaQQiJ/a5Kr4+o/mn67C1RmoD84Nj wlcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767683255; x=1768288055; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Tsuh7/jn2jrlTYfOWGAUThNB0B3UU7lnuVu7OzAU18M=; b=lP84yhSoSk4Yzd+QJzY9MOXF46NiU+xOoHgpXJ9uUjfDXZtRd+tVRfDKLu7f8Q9s0E cStRQAtQJrf9gQ7lYGiNbjeYLoLfalBc63GqIqa+AsvbVwfEQW5xcOY9bTCD65hjUOMQ sgqldjv13FaeWpm1Oo447x5f8DkshRTpvk2AnfR1J5np3sTuXVWCsoy7E4cnR05Au011 uAHZiezA77IbPTxJHUI1gXWfvthXnEKXoBYh2yE+CbUf4zIS5I2maDayEDfe4MlnOPYz T1unBRE0FlXPBYQNbS9rQyfNmEfobIi8vxSxwbz7uibDDBM+d6YTJsLIw4Uh5r74dsW9 xU1A== X-Forwarded-Encrypted: i=1; AJvYcCXacl4/J+MCYEarQbdO7h5uHBhGb/1H55IuvBq5YHYG/LVlLfoYY2KoGN66NF00e1Y/PqF221m/xtXeeZc=@vger.kernel.org X-Gm-Message-State: AOJu0YxI2wePc77H7Ky9Pev6vxQTeUcSLfwmd+bRGOoYoZytQlHaiS9N 5D3oUmr6gt+bC505zfx6ai5VgyLiEg0ol/VlTSbciZNEIbKcLxW05/Um X-Gm-Gg: AY/fxX6TYXJOKLEU1eFOccT6tXyHojHfBylS9w3/Eax9T5/YGVskWP4SHpOMCREjqcf kk5nrqEKvLjYWcRW+raY4PGvoc/blBDpF7eH6PcVgHkUJBs8zae1+jr5DQ4ZepCrjFYDeyVHlgC thAQ9mgC4HU9Hv7j5CFJuMd81uAIwdOB9YGBb0nZW2LIE+xhZHQQIcjfj6MgDWvf5RV+JlNfqSQ PUYj/rcohXRSadwNyADBGORdNHWUwEzf67euhoUshtd4hSfDML+mpt2t09W/jbHGdobKjYXFDG2 KRXmD59BN9Hicnoa+qEyPWMIDFaU3/JCE7QZUk/h+SE/Z/5fJ4Dio0lmnux+ccHIz6F/130zyiR pTmeipUFFcwiMj4AHHA7tQ/61mPzrU1l2qAoG3Iah1cZ6GZJgSI2yuKIns6nu+03U7/2djDrGyI wIwCJUhdOhwI6uOPo+6FazU68pLr1+SilkbOEe3w== X-Google-Smtp-Source: AGHT+IEsD88EaPwiMhccJF3RlZqPs9pS1phTsauuJqeQyjGPNnQL5fHxPRx3Z8nWoBg/iLAcN8Vlsw== X-Received: by 2002:a17:903:90f:b0:29f:301a:f6d2 with SMTP id d9443c01a7336-2a3e2d9e01fmr16747605ad.19.1767683254860; Mon, 05 Jan 2026 23:07:34 -0800 (PST) Received: from lima-ubuntu.hz.ali.com ([47.246.98.217]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a3e3cc88f1sm11768465ad.78.2026.01.05.23.07.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 23:07:34 -0800 (PST) From: Qing Wang To: akpm@linux-foundation.org Cc: Liam.Howlett@oracle.com, brauner@kernel.org, bsegall@google.com, david@kernel.org, dietmar.eggemann@arm.com, jack@suse.cz, joel.granados@kernel.org, juri.lelli@redhat.com, keescook@chomium.org, linux-kernel@vger.kernel.org, lorenzo.stoakes@oracle.com, mingo@redhat.com, mjguzik@gmail.com, oleg@redhat.com, peterz@infradead.org, rostedt@goodmis.org, rppt@kernel.org, syzbot+e0378d4f4fe57aa2bdd0@syzkaller.appspotmail.com, vbabka@suse.cz, vincent.guittot@linaro.org, wangqing7171@gmail.com Subject: Re: [PATCH] fork/pid: Fix use-after-free in __task_pid_nr_ns Date: Tue, 6 Jan 2026 15:07:22 +0800 Message-Id: <20260106070723.2313045-1-wangqing7171@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260105144641.5dcce6cdeac8514580d3cd14@linux-foundation.org> References: <20260105144641.5dcce6cdeac8514580d3cd14@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit > It might be helpful to have a comment here telling readers how > task->signal can be zero. > > Also, what in here prevents task->signal from being zeroed after we've > tested it and before we dereference it? Thank you for your feedback. Regarding the "test-and-use" race condition you raised, I’ve thought about it extensively but haven’t found a better solution on the access side. However, after re-examining the issue, I guess the root cause lies in the copy_process() flow itself, and we may not need complex handling at the access site: 1. The signal_struct is not fully managed by reference counting: In the normal (successful) path of copy_process(), the signal structure is indeed reference-counted, and its lifetime should be at least longer than the task’s. However, in the failure/cleanup path, signal is explicitly freed via free_signal_struct(), which prematurely ends its lifetime. At the same time, other subsystems (e.g., perf) might still hold references and attempt to access it—even if such access may be questionable. 2. A newly created task should not be visible to other CPUs during creation: The perf subsystem copies the parent’s events to the child during copy_process(). Later, when the parent closes or manipulates its own perf event, it may traverse child events and access child_ctx->task->signal. This means that a child process that has not yet been fully created can be referenced by other CPUs. Based on this analysis, I propose two possible fixes—either one should resolve the issue: 1. Remove the explicit free_signal() in the cleanup path, and fully managed by reference counting for signal lifetime. Currently put_signal_struct() is only used in __put_task_struct(), so the lifetime of signal is longer than or equal to task. 2. Defer perf_event_init_task() until after copy_signal() succeeds, ensuring that if copy_process() failed perf events will be cleaned up before the signal. This guarantees that no perf event can access the signal. I believe either approach would eliminate the issue. Could you please review whether this analysis and the proposed solutions are correct? Any guidance would be greatly appreciated.