Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp309052pxf; Thu, 8 Apr 2021 03:40:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzZLAWP6Ub1Mxyb7ii7Y3MHEoWoX2nF3aBafilYPa0mq13KTf05IweswK/9ra3jXwiPL/5O X-Received: by 2002:a65:5bca:: with SMTP id o10mr7636930pgr.248.1617878420069; Thu, 08 Apr 2021 03:40:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617878420; cv=none; d=google.com; s=arc-20160816; b=aKjkcS/v5/XxXkNubZAs0/KFkVbGjoxHUl/fPwMzq5+hAI/tEDKTPLbcLNKojS6UzD BDoDskcTTKI+Q6Bz2HyT8EZO8xwoW8eqqHc0C5fgoWHkXnoX6CxK6SMdOY97BE/madnr tjvhqi7vaF20nUMoWCiq6/RFyJ29ounJOhQskALYo989RvqJEA0AsMaUk3URIyHXBoBL /CVzQNO/PnoKTuXSuSHNxzfR8goWW/YNIP473bnPpPYWULLBIZuq6R4fIULnWAF7Nte9 S5TIcBlVhE4+qB1NLdWTtUnezcLaiWp3ofAaTiZNRQG1guTx2CXFDaOLQ2d8k6UQlJIV PlcA== 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; bh=2Z5xwV77hcz5ZwPud9+tKyLC7ADEfp+p5urpjDRfGhQ=; b=MHYWw0Ml/4MjEDH3j2A2yrnLDDf0v4snuWcHsGHZ2lAiBlDGSrLxWEPbDUnzXk7FOi Ln16V5m24WjTdBnDbmLP7lZKnPo6FZ/xQSnc5PpLz8cxsuwdg5OmtaJernfeiFJAtEZ5 gxHl63GTAvRGEa1v8CbXFcfBAnAuL2GNNKt0gQNcJV76rg+TuQ/u2GntP98yO4mLiP+8 KnFPDvp8yWsrmZTb3JJbHcv+c4XT2wgiX6fqLIDi40EspXLMukN0k+NRSmLwxgpezxDD yqK4kAJWMjrM+HFvIEllEj2wD0YBo4c27sCUIqeNBc4nZichHeRyWEiHsiULuPf3HSP7 INFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u16si12347680plf.123.2021.04.08.03.40.07; Thu, 08 Apr 2021 03:40:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231133AbhDHKid (ORCPT + 99 others); Thu, 8 Apr 2021 06:38:33 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:51176 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231460AbhDHKhv (ORCPT ); Thu, 8 Apr 2021 06:37:51 -0400 Received: from ip5f5bf209.dynamic.kabel-deutschland.de ([95.91.242.9] helo=wittgenstein.fritz.box) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lUS2d-0004fv-0b; Thu, 08 Apr 2021 10:37:39 +0000 From: Christian Brauner To: Linus Torvalds Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [GIT PULL] close_range fix Date: Thu, 8 Apr 2021 12:36:18 +0200 Message-Id: <20210408103618.1206025-1-christian.brauner@ubuntu.com> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Linus, /* Summary */ Syzbot reported a bug in close_range. Debugging this showed we didn't recalculate the current maximum fd number for CLOSE_RANGE_UNSHARE | CLOSE_RANGE_CLOEXEC after we unshared the file descriptors table. So max_fd could exceed the current fdtable maximum causing us to set excessive bits. As a concrete example, let's say the user requested everything from fd 4 to ~0UL to be closed and their current fdtable size is 256 with their highest open fd being 4. With CLOSE_RANGE_UNSHARE the caller will end up with a new fdtable which has room for 64 file descriptors since that is the lowest fdtable size we accept. But now max_fd will still point to 255 and needs to be adjusted. Fix this by retrieving the correct maximum fd value in __range_cloexec(). I've carried this fix for a little while but since there was no linux-next release over easter I waited until now. With this change close_range() can be simplified a bit but imho we are in no hurry to do that and so I'll defer this for the 5.13 merge window. (Fwiw, the two follow-up patches sit in https://git.kernel.org/brauner/h/fs/close_range.) /* Testing */ All patches have seen exposure in linux-next and are based on v5.12-rc4. The selftests pass and the reproducer provided by syzbot did not trigger. The patch also has a Tested-by from Dmitry but I had already pushed it out by the time that came in so it's missing from the patch itself. /* Conflicts */ At the time of creating this pr no merge conflicts were reported. A test merge and build with today's master 2021-04-08 12:20:00 CET worked fine. The following changes since commit 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b: Linux 5.12-rc4 (2021-03-21 14:56:43 -0700) are available in the Git repository at: git@gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux tags/for-linus-2021-04-08 for you to fetch changes up to 9b5b872215fe6d1ca6a1ef411f130bd58e269012: file: fix close_range() for unshare+cloexec (2021-04-02 14:11:10 +0200) Please consider pulling these changes from the signed for-linus-2021-04-08 tag. Thanks! Christian ---------------------------------------------------------------- for-linus-2021-04-08 ---------------------------------------------------------------- Christian Brauner (1): file: fix close_range() for unshare+cloexec fs/file.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-)