From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from cyan.elm.relay.mailchannels.net (cyan.elm.relay.mailchannels.net [23.83.212.47]) (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 9924D38F24C for ; Mon, 6 Apr 2026 19:33:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=23.83.212.47 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775504014; cv=pass; b=rDV4/fUQzxFYYFjrQtCzmbDZaUzLn79etEaSoJpHPRdOYuZo6jsotQXvjVLPFYS+xm8yjDLPJiT/Q6/yo/BHV943ap7IIOLzSbHEnGA7KFXO4lDm+Mf+JXkcSPGDbHT8WcWw1/w9RWnEQ+H9IzXS0YoPGdobZoxaTf6hqDN+R2k= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775504014; c=relaxed/simple; bh=yc697il75ADjfV8zk6Vw2QTH7vVV09M+QWZEQXeikqs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k9DnqJmOcE2uyHeAmeHmbr7bmgXUYkKZva6LDWForyKpmTcEux4D7QHf0oJ0OSwu/Lm8N8N2hpUeq2iyFNKwO1SJ2pNTW5b1cZib5pdiLvcagmhAZTTFuQztExiO8g9DsYz5sOLWqo9fQTkEa98l8BfmtlX4oJ7lysCVVtE0Ip4= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=stgolabs.net; spf=fail smtp.mailfrom=stgolabs.net; dkim=pass (2048-bit key) header.d=stgolabs.net header.i=@stgolabs.net header.b=fAJRsNUu; arc=pass smtp.client-ip=23.83.212.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=stgolabs.net Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=stgolabs.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=stgolabs.net header.i=@stgolabs.net header.b="fAJRsNUu" X-Sender-Id: dreamhost|x-authsender|dave@stgolabs.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 8F2EB18366A; Mon, 06 Apr 2026 19:33:26 +0000 (UTC) Received: from pdx1-sub0-mail-a229.dreamhost.com (100-121-211-194.trex-nlb.outbound.svc.cluster.local [100.121.211.194]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 0491B182DFB; Mon, 06 Apr 2026 19:33:25 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; d=mailchannels.net; s=arc-2022; cv=none; t=1775504006; b=wqLG2YHOmApL8QhP1zAZap+xEyuwSpz1gfd96dpqWPr1x2EBpcst2c661+PCpRfOyrFPxP +jBMkviIAv6m6ASs7K7BeN5yjZPyryWNmPUlhCLDhxqUYzHVQvT2NVF5ahczEmXm22WJCT T5zixziXuK/4IVHuiPYBTwJyLQRok5VgU5mkiKSHQ/A8fb5S72bniozszqiLbDSLMAN9s3 kthfQw0vi0fpwfJjvUGuEXcQd4Ga/rVymbumA+B0XPWXo+PWjedRA85vZ7dDvPEDWtkXm+ BvE4iADjxB51LJq8BVlElB05VauQtVmKDIBnQRl+tZicmkV2SRxYB8n+ZPq7VA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1775504006; 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:dkim-signature; bh=z+ck7vkpY/K1MJHADlL4VzaeGWc3JQ4WiAH9WsTDRSs=; b=I1FUqZ0LvB1Qzs85mCuL6AC4BH1U8xhhUEiQGy9FqfFtfr5MjSZGeK7oQgbsW7IG6PlKwL CBRgCH7/SjZ5BxRZBWr0ZN5ce7Rgze5XtjWPG1GNbJzfnk5lcYEvJNzMhwYamhfQ6s2cnB MN3xlBhIpPCEZ3hl/MsZVSQzvocCBnE8DWfjcUWDO5uuNUL9mEi7U2gxafbtLT7uH/2cQq JEoSgaacyoFuhOJJq3vYqsLGbI0d/nh6VOvVx3SIwuzMa+boDHalBveS5M+kt9+d5Lsfb3 BMXqd1Ss9Il4ttH0Noufj9P7aDPZ79RtUo1Sb3qsiSNux9WttXa9C0RkrX/6KQ== ARC-Authentication-Results: i=1; rspamd-7d86dcc447-gb4xv; auth=pass smtp.auth=dreamhost smtp.mailfrom=dave@stgolabs.net X-Sender-Id: dreamhost|x-authsender|dave@stgolabs.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|dave@stgolabs.net X-MailChannels-Auth-Id: dreamhost X-Bored-Interest: 4bc60e12076f2071_1775504006438_21859200 X-MC-Loop-Signature: 1775504006438:1135160999 X-MC-Ingress-Time: 1775504006438 Received: from pdx1-sub0-mail-a229.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.121.211.194 (trex/7.1.5); Mon, 06 Apr 2026 19:33:26 +0000 Received: from offworld (unknown [76.167.199.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dave@stgolabs.net) by pdx1-sub0-mail-a229.dreamhost.com (Postfix) with ESMTPSA id 4fqKHn0jqTzTZ; Mon, 6 Apr 2026 12:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stgolabs.net; s=dreamhost; t=1775504005; bh=z+ck7vkpY/K1MJHADlL4VzaeGWc3JQ4WiAH9WsTDRSs=; h=Date:From:To:Cc:Subject:Content-Type; b=fAJRsNUuBPZplea/f/d3D8DFfA8TKrzQhUcpRzVxzMOCdoqSjquObzDscqClzgfz2 1Ldo60o/oe41EQz/mFwYJXQRiddmzsu0Haa3I8VatrNCgSrg6xAh4M5jOJYNRREPLS V467nHwrVHF3rtaz0b4XQL8ZurclKyMVOjGSg33E8QmigFV5FOoxzRdb5jDVQupfwE yk3TcR0GDAJn532kPi+Gh5SQJH2Ou/B9jTnVX0hKk92upYoFuOYD3Jg9Kq2wwGrBxo 3vYii0MBfCCC4t47Osbp+lOSTRSJ5fOI2xDai7nMrdRHgb+17wLcvbh2uGIll8n2+W OCScfmqGcE7nQ== Date: Mon, 6 Apr 2026 12:33:22 -0700 From: Davidlohr Bueso To: Xiang Mei Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org, ljs@kernel.org, Liam.Howlett@oracle.com, brauner@kernel.org, baolin.wang@linux.alibaba.com, aha310510@gmail.com, kees@kernel.org, bestswngs@gmail.com, manfred@colorfullife.com Subject: Re: [PATCH ipc] ipc/shm: fix race between shm_try_destroy_orphaned and do_shmat Message-ID: <20260406193322.cu2rrtfmpixlv7yy@offworld> References: <20260329013646.1188553-1-xmei5@asu.edu> 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=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20260329013646.1188553-1-xmei5@asu.edu> User-Agent: NeoMutt/20220429 Cc Manfred. On Sat, 28 Mar 2026, Xiang Mei wrote: >shm_try_destroy_orphaned() reads shm_nattch via shm_may_destroy() >without holding the per-object spinlock, relying on rwsem alone for >synchronization. However, do_shmat() modifies shm_nattch under the >per-object spinlock (not rwsem), creating a TOCTOU race: > > CPU 0 (do_shmat) CPU 1 (shm_try_destroy_orphaned) > ipc_lock_object() > shm_nattch++ (0 -> 1) > ipc_unlock_object() > shm_may_destroy() -> reads stale nattch==0 > shm_lock_by_ptr() > shm_destroy() // nattch is actually 1! More like: CPU 0 (do_shmat) CPU 1 (shm_try_destroy_orphaned) ipc_lock_object() shm_may_destroy() -> reads nattch==0 shm_nattch++ (0 -> 1) ipc_unlock_object() shm_lock_by_ptr() shm_destroy() // nattch is actually 1! >The segment is destroyed while do_shmat() has already incremented >shm_nattch and is proceeding with the mmap setup. When do_shmat() >later reaches out_nattch, shm_lock() returns ERR_PTR (the IDR entry >was removed by shm_destroy) and the code dereferences it without an >IS_ERR() check, causing a null-ptr-deref crash: I think that an IS_ERR() check should also be added to do_shmat(), it makes the code more robust (mitigating the actual bug fixed here to not trigger the crash). > > BUG: kernel NULL pointer dereference, address: 0000000000000072 > RIP: 0010:do_shmat (ipc/shm.c:1678) > Call Trace: > __x64_sys_shmat (ipc/shm.c:1699 ipc/shm.c:1693 ipc/shm.c:1693) > do_syscall_64 (arch/x86/entry/syscall_64.c:94) > [...] > >Fix by taking the object lock before checking shm_may_destroy() in >shm_try_destroy_orphaned(), so the check sees the up-to-date value >of shm_nattch. It's probably fine to unconditionally take the object lock in this path (not performance critical). But I think it might be better to just re-check shm_may_destroy() after taking the lock. > >Fixes: 4c677e2eefdb ("shm: optimize locking and ipc_namespace getting") Old bug, seems not many users of shm_rmid_forced. Thanks, Davidlohr >Reported-by: Weiming Shi >Signed-off-by: Xiang Mei >--- > ipc/shm.c | 13 +++++++------ > 1 file changed, 7 insertions(+), 6 deletions(-) > >diff --git a/ipc/shm.c b/ipc/shm.c >index a95dae447707..50f9aa7ff33a 100644 >--- a/ipc/shm.c >+++ b/ipc/shm.c >@@ -416,17 +416,18 @@ static int shm_try_destroy_orphaned(int id, void *p, void *data) > > /* > * We want to destroy segments without users and with already >- * exit'ed originating process. >- * >- * As shp->* are changed under rwsem, it's safe to skip shp locking. >+ * exit'ed originating process. Take the object lock before >+ * checking shm_may_destroy() since shm_nattch can be modified >+ * under the object lock alone (e.g. by do_shmat). > */ > if (!list_empty(&shp->shm_clist)) > return 0; > >- if (shm_may_destroy(shp)) { >- shm_lock_by_ptr(shp); >+ shm_lock_by_ptr(shp); >+ if (shm_may_destroy(shp)) > shm_destroy(ns, shp); >- } >+ else >+ shm_unlock(shp); > return 0; > } > >-- >2.43.0 >