Received: by 2002:a05:622a:1442:b0:3a5:28ea:c4b9 with SMTP id v2csp689647qtx; Mon, 31 Oct 2022 11:28:21 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7tdWMlcHQGIMaOrF7gOjcm6n0ZC08J7MsCsYGKMWVdTNOuXZb1LgCnRHneZqNdmg3FL5eK X-Received: by 2002:a17:902:f641:b0:17f:3633:5439 with SMTP id m1-20020a170902f64100b0017f36335439mr15827046plg.94.1667240901553; Mon, 31 Oct 2022 11:28:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667240901; cv=none; d=google.com; s=arc-20160816; b=Irn7h7XvWuarFfmSvsupqro+Z2D5w2ofBFt4CcEWUYmuBqpPQa85wVNZf4jaVW/Es7 Sls+gzpY+HSMJtD4fxwShHA5OSIie6pPwaq8QK2oeI2rRoxtWNwxLgTkNjML0pfonagP tXEL733Zq3NU8lTMshvigOOwnlj4HXSf6tNkSiovYXKheFyQse5JVLJ4rZOi0LrqKl6C 0in7lh3wfnke2gGAMC7ACmc1HDYmAGPIdYv1/Yu2DZVWu8NTWo4MhgfFZW1JDzIaz4+f EiZCBXPj6sfuyuUixPxbXM4VPgY988vY5Xf5U8ASm+fpwPmdGb1SKA4Nle7VhupA7NB4 VVOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=U7UbF4nZPug8lSmlrO1tsRcqhQZwCNdlA+12Y/ynwzs=; b=bK1XWLvDqik1JNFbmghGctD5fYDd0I7voK7W1Q5pMSQFtRLvqZCP3Lnq4XSDvKCMg4 jTOCVAsdrly6ig6c7GqROh7QkD7O/8ds8u0lKFKJn2fLRoY35/Jr76OAuL+hSLyaMo6y KcBHF1nP9ICkfhFXxsB0aq/ZCMJzEGEkH5CQsnh15/ZChJJV0oqZdYwRZBSnqpCoZlwQ LNS6gDBIz5BqYPmbYuyakiS053sk5dWBeu5kSq4jLEjd21DLPc/wUDOiEyXpG/6/UEGH q4Bj0CNvUU2LFbMQnC59DCD5Joa1XkqW9SHJlPxL8AeBXDHvKVrebSVrpE7JVLO+c2wc noQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Y097of5r; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c3-20020a170902d48300b001841134e3b1si11595237plg.160.2022.10.31.11.28.07; Mon, 31 Oct 2022 11:28:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Y097of5r; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230099AbiJaRxN (ORCPT + 98 others); Mon, 31 Oct 2022 13:53:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231302AbiJaRxF (ORCPT ); Mon, 31 Oct 2022 13:53:05 -0400 Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD17913D60 for ; Mon, 31 Oct 2022 10:53:03 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id z14so17031842wrn.7 for ; Mon, 31 Oct 2022 10:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=U7UbF4nZPug8lSmlrO1tsRcqhQZwCNdlA+12Y/ynwzs=; b=Y097of5rV70g0ZvYp+B8s8y1ErB3xlFNDaYW6ykJJYNatkuqJlr+z+CyX0O3OdoplY 3mu+Og8NL2wgCY/UedkxZg/63j/icDlf6ELFCdMtov2T/caOd8nStl63B1f6Ng8tcU1M 5hgV7wZQwyNOFnJIJGLc7IfcKpyE6ArcZAM/dMQojkvPcXsLX6wzBQ4wxV0vVsqUBgQo nlt47HP/JLDJZw1BxKGWt8/cguUb1ck9UcwvtLChSK4ybEORV7tsGUXsaKD8Z+PJmzIw A5XIJIsaFJUKt+TXFuyjzrL8cPOIZQL4DK4C9/b8ysCbhMYRzIA+6uJ2wpervRsmuhoV ljgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=U7UbF4nZPug8lSmlrO1tsRcqhQZwCNdlA+12Y/ynwzs=; b=k24gl1V8bmboiqveqEeYBnZidfI7ZLPqQoUfCJgTVrS2DxyODSQuqoOPRMn2kpFRJY nzgc4rgD+J7+O6WAYjpGtJCS/8C2LWkZOJ+jJMV4aoEHkTVefnSHnmAOG5AvUHMRuw2r lR/J2naSgGocpRMpPAfh4X43WhR84Xg9J5NfOI6fBPf9rmOpyNeIeCXhO7VE/IZN4AvM mOd9bxEGr5blg8vSC1QK2II/Ww9VP6Ucik5IXPPwIGohsfuG8OPm+zMlRW4p4mFV+nrq YYJJU+30Sf1v9d8DW84TdCW4Rcmv8KP+NLo4EkLli2Q8GO6E2g4OYLg/4iy+PLviQDGc f4Kg== X-Gm-Message-State: ACrzQf0HTzcmTFVW3+CDjmU0DzxZjbtrTO6yJT3L5HaoCirCseUvnlox S+alLm6uZ77e145RgJTlY8UV8g== X-Received: by 2002:a05:6000:1841:b0:236:70dc:1a6f with SMTP id c1-20020a056000184100b0023670dc1a6fmr9096259wri.464.1667238782105; Mon, 31 Oct 2022 10:53:02 -0700 (PDT) Received: from localhost ([2a00:79e0:9d:4:f03a:db2e:7a5c:b47c]) by smtp.gmail.com with ESMTPSA id w12-20020a5d404c000000b002365254ea42sm7937270wrp.1.2022.10.31.10.53.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Oct 2022 10:53:01 -0700 (PDT) From: Jann Horn To: Al Viro Cc: Linus Torvalds , Miklos Szeredi , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Will Deacon Subject: [PATCH v2] fs: use acquire ordering in __fget_light() Date: Mon, 31 Oct 2022 18:52:56 +0100 Message-Id: <20221031175256.2813280-1-jannh@google.com> X-Mailer: git-send-email 2.38.1.273.g43a17bfeac-goog MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We must prevent the CPU from reordering the files->count read with the FD table access like this, on architectures where read-read reordering is possible: files_lookup_fd_raw() close_fd() put_files_struct() atomic_read(&files->count) I would like to mark this for stable, but the stable rules explicitly say "no theoretical races", and given that the FD table pointer and files->count are explicitly stored in the same cacheline, this sort of reordering seems quite unlikely in practice... Signed-off-by: Jann Horn --- fs/file.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/fs/file.c b/fs/file.c index 5f9c802a5d8d3..c942c89ca4cda 100644 --- a/fs/file.c +++ b/fs/file.c @@ -1003,7 +1003,16 @@ static unsigned long __fget_light(unsigned int fd, f= mode_t mask) struct files_struct *files =3D current->files; struct file *file; =20 - if (atomic_read(&files->count) =3D=3D 1) { + /* + * If another thread is concurrently calling close_fd() followed + * by put_files_struct(), we must not observe the old table + * entry combined with the new refcount - otherwise we could + * return a file that is concurrently being freed. + * + * atomic_read_acquire() pairs with atomic_dec_and_test() in + * put_files_struct(). + */ + if (atomic_read_acquire(&files->count) =3D=3D 1) { file =3D files_lookup_fd_raw(files, fd); if (!file || unlikely(file->f_mode & mask)) return 0; base-commit: 30a0b95b1335e12efef89dd78518ed3e4a71a763 --=20 2.38.1.273.g43a17bfeac-goog