All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: linux-fsdevel@vger.kernel.org
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Dmitry Vyukov <dvyukov@google.com>,
	Christian Brauner <christian.brauner@ubuntu.com>
Subject: [PATCH 0/3] file: fix and simplify close_range()
Date: Fri,  2 Apr 2021 14:35:45 +0200	[thread overview]
Message-ID: <20210402123548.108372-1-brauner@kernel.org> (raw)
In-Reply-To: <00000000000069c40405be6bdad4@google.com>

From: Christian Brauner <christian.brauner@ubuntu.com>

Hey,

This fixes the syzbot report that Dmitry took time to give a better
reproducer for. 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 and simplify the logic in close_range(), getting rid of the
double-checking of max_fd and the convoluted logic around that.
(There some data on how close_range() is currently used in userspace
 which I've mentioned in the original thread. It's interesting as most
 users have switched to CLOSE_RANGE_CLOEXEC pretty quickly apart from
 those where a lot of fds need to be closed and it isn't clear when or
 if exec happens (e.g. systemd and the massive amounts of fds it can
 inherit due to socket activation).)
I've stuffed it in a branch at 
https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=fs/close_range

I just didn't have time to get back to tweak the fix sooner than today.
A version of this has been sitting in linux-next for a while though.
If there's no braino from my side I'd like to get this to Linus rather
sooner than later so the bug is fixed as it's been some time now.

Thanks!
Christian

Christian Brauner (3):
  file: fix close_range() for unshare+cloexec
  file: let pick_file() tell caller it's done
  file: simplify logic in __close_range()

 fs/file.c | 85 +++++++++++++++++++++++++++++++++++++------------------
 1 file changed, 57 insertions(+), 28 deletions(-)


base-commit: 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b
-- 
2.27.0


  parent reply	other threads:[~2021-04-02 12:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26  7:55 [syzbot] KASAN: null-ptr-deref Read in filp_close (2) syzbot
2021-03-26  8:02 ` Dmitry Vyukov
2021-03-26  9:12   ` Christian Brauner
2021-03-26  9:21     ` Dmitry Vyukov
     [not found]       ` <CAHrFyr7iUpMh4sicxrMWwaUHKteU=qHt-1O-3hojAAX3d5879Q@mail.gmail.com>
2021-03-26 13:50         ` Christian Brauner
2021-03-26 14:22           ` Dmitry Vyukov
2021-03-27 23:33           ` Al Viro
2021-03-29  9:21             ` Christian Brauner
2021-03-29 17:35               ` Christian Brauner
2021-04-02 12:35 ` Christian Brauner [this message]
2021-04-02 12:35 ` [PATCH 1/3] file: fix close_range() for unshare+cloexec Christian Brauner
2021-04-02 12:35 ` [PATCH 2/3] file: let pick_file() tell caller it's done Christian Brauner
2021-04-02 20:09   ` kernel test robot
2021-04-02 12:35 ` [PATCH 3/3] file: simplify logic in __close_range() Christian Brauner
2021-07-13  4:12 ` [syzbot] KASAN: null-ptr-deref Read in filp_close (2) syzbot
2021-07-13 18:49   ` Linus Torvalds
2021-07-14  7:59     ` Christian Brauner
2021-07-14  9:14       ` Christian Brauner
2021-07-14 11:45       ` Dmitry Vyukov
2021-07-14 13:51   ` Christian Brauner
2021-07-14 13:54     ` syzbot
2021-07-14 13:57     ` Christian Brauner
2021-07-14 14:16       ` syzbot
2021-07-14 13:53   ` Christian Brauner
2021-07-14 13:53     ` syzbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210402123548.108372-1-brauner@kernel.org \
    --to=brauner@kernel.org \
    --cc=christian.brauner@ubuntu.com \
    --cc=dvyukov@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.