Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp2569761pxf; Sat, 27 Mar 2021 16:35:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz5u0psyvxl8tLoygiigG2g4S6hlJj3+EL47hjn35dh5uQdM+4ZM5sBL2sIxbUWZ0d2H3RU X-Received: by 2002:a17:906:7f12:: with SMTP id d18mr21416496ejr.368.1616888151290; Sat, 27 Mar 2021 16:35:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616888151; cv=none; d=google.com; s=arc-20160816; b=KsnjEvtM01xBfvtrEb1pfS38CIP4eb7L46lkGtvuNQIlz2qT8mpstXnUXsDLmPpxd+ C7tE6etUy8iz6w72H3sWPnR/3EFTAQYChuNSc423NRpKvJBsSU+J2MXNrGQM8UzLywae NDjA4j1UfMSVhjJ+gR8qv/C4EYwr9oO8HeXC1PYUag7NMy5Pk+5GcHgGJDuNe0RiFZUZ LCpGU3AbhaPqW+M12uE/wr9+itVB49JH4ECJa8v2O7IkdZ7vY+nfLOdLJ2D+1rj8LK40 mwC+YQg0hhTS9aH4lK/yq8Aiy5Ijlj4s07ncpWY6eAtKw0sBvMA59jH3EHh/OGbOPc/B dSeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=5/MqthJ5RAx53W9tBheutfODEPQmELFNQ8nlZkEWh+M=; b=SCFEgoU0jy80C1kMTPdXLub9csfyTMvfaRADeeQ9seITh5Qvo26BqZxSFabg/5d9ZD +mTniqPJimxO36mW1nv9OFgzn1cdiS4s9j+B5TshWnAJBHnMxsvnnVNMB5pjhHLuPzMR 0x53DlQFK3GsxIED2cHw/P46skUxLRpAq30od/wKUXuzoLXrr4DNFuhpfQE6T7+vJT9g Bo6bPzE1Q3o9JDep6P2Rcd7JV0as0XgR/Hv2HHliZZ/7wIJWobNcHgZbpkkgMJaO9fKl J+uU6Tui4/l7OhoodC/EdMaGzJ9rK56fhkOkGYOMdZikJKaczy88oVwtBrYdxdZAIKif EhJg== 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 cf26si9689125ejb.702.2021.03.27.16.35.28; Sat, 27 Mar 2021 16:35:51 -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 S230526AbhC0XeG (ORCPT + 99 others); Sat, 27 Mar 2021 19:34:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230442AbhC0Xds (ORCPT ); Sat, 27 Mar 2021 19:33:48 -0400 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 216FEC0613B1; Sat, 27 Mar 2021 16:33:47 -0700 (PDT) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94 #2 (Red Hat Linux)) id 1lQIQz-000KUP-T2; Sat, 27 Mar 2021 23:33:38 +0000 Date: Sat, 27 Mar 2021 23:33:37 +0000 From: Al Viro To: Christian Brauner Cc: Dmitry Vyukov , syzbot , linux-fsdevel , LKML , syzkaller-bugs Subject: Re: [syzbot] KASAN: null-ptr-deref Read in filp_close (2) Message-ID: References: <00000000000069c40405be6bdad4@google.com> <20210326091207.5si6knxs7tn6rmod@wittgenstein> <20210326135011.wscs4pxal7vvsmmw@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210326135011.wscs4pxal7vvsmmw@wittgenstein> Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 26, 2021 at 02:50:11PM +0100, Christian Brauner wrote: > @@ -632,6 +632,7 @@ EXPORT_SYMBOL(close_fd); /* for ksys_close() */ > static inline void __range_cloexec(struct files_struct *cur_fds, > unsigned int fd, unsigned int max_fd) > { > + unsigned int cur_max; > struct fdtable *fdt; > > if (fd > max_fd) > @@ -639,7 +640,12 @@ static inline void __range_cloexec(struct files_struct *cur_fds, > > spin_lock(&cur_fds->file_lock); > fdt = files_fdtable(cur_fds); > - bitmap_set(fdt->close_on_exec, fd, max_fd - fd + 1); > + /* make very sure we're using the correct maximum value */ > + cur_max = fdt->max_fds; > + cur_max--; > + cur_max = min(max_fd, cur_max); > + if (fd <= cur_max) > + bitmap_set(fdt->close_on_exec, fd, cur_max - fd + 1); > spin_unlock(&cur_fds->file_lock); > } Umm... That's harder to follow than it ought to be. What's the point of having max_fd = min(max_fd, cur_max); done in the caller, anyway? Note that in __range_close() you have to compare with re-fetched ->max_fds (look at pick_file()), so... BTW, I really wonder if the cost of jerking ->file_lock up and down in that loop in __range_close() is negligible. What values do we typically get from callers and how sparse does descriptor table tend to be for those?