From: Christian Brauner <brauner@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Fedor Pchelkin <aissur0002@gmail.com>,
Alexey Khoroshilov <khoroshilov@ispras.ru>,
Eric Biggers <ebiggers@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/4] file: Fix file descriptor leak in copy_fd_bitmaps()
Date: Tue, 29 Mar 2022 12:23:47 +0200 [thread overview]
Message-ID: <20220329102347.iu6mlbv5c76ci3j7@wittgenstein> (raw)
In-Reply-To: <CAHk-=wh2Ao+OgnWSxHsJodXiLwtaUndXSkuhh9yKnA3iXyBLEA@mail.gmail.com>
On Sun, Mar 27, 2022 at 03:21:18PM -0700, Linus Torvalds wrote:
> On Sun, Mar 27, 2022 at 2:53 PM <aissur0002@gmail.com> wrote:
> >
> > I am sorry, that was my first attempt to contribute to the kernel and
> > I messed up a little bit with the patch tag: it is actually a single,
> > standalone patch and there has been nothing posted previously.
>
> No problem, thanks for clarifying.
>
> But the patch itself in that case is missing some detail, since it
> clearly doesn't apply to upstream.
>
> Anyway:
>
> > In few words, an error occurs while executing close_range() call with
> > CLOSE_RANGE_UNSHARE flag: in __close_range() the value of
> > max_unshare_fds (later used as max_fds in dup_fd() and copy_fd_bitmaps())
> > can be an arbitrary number.
> >
> > if (max_fd >= last_fd(files_fdtable(cur_fds)))
> > max_unshare_fds = fd;
> >
> > and not be a multiple of BITS_PER_LONG or BITS_PER_BYTE.
>
> Very good, that's the piece I was missing. I only looked in fs/file.c,
> and missed how that max_unshare_fds gets passed from __close_range()
> into fork.c for unshare_fd() and then back to file.c and dup_fd(). And
> then affects sane_fdtable_size().
>
> I _think_ it should be sufficient to just do something like
>
> max_fds = ALIGN(max_fds, BITS_PER_LONG)
>
> in sane_fdtable_size(), but honestly, I haven't actually thought about
> it all that much. That's just a gut feel without really analyzing
> things - sane_fdtable_size() really should never return a value that
> isn't BITS_PER_LONG aligned.
>
> And that whole close_range() is why I added Christian Brauner to the
> participant list, though, so let's see if Christian has any comments.
>
> Christian?
(Sorry, I was heads-deep in some other fs work and went into airplaine
mode. I'm back.)
So I investigated a similar report a little while back and I spent quite
a lot of time trying to track this down but didn't find the cause.
If you'd call:
close_range(131, -1, CLOSE_RANGE_UNSHARE);
for an fdtable that is smaller than 131 then we'd call:
unshare_fd(..., 131)
\dup_fd(..., 131)
\sane_fdtable_size(..., 131)
So sane_fdtable_size() would return 131 which is not aligned. This
couldn't happen before CLOSE_RANGE_UNSHARE afaict. I'll try to do a
repro with this with your suggested fix applied.
Christian
next prev parent reply other threads:[~2022-03-29 10:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-26 11:40 Fedor Pchelkin
2022-03-26 14:17 ` Alexey Khoroshilov
2022-03-26 22:15 ` Linus Torvalds
2022-03-26 22:37 ` Linus Torvalds
2022-03-27 21:54 ` aissur0002
2022-03-27 22:21 ` Linus Torvalds
2022-03-29 10:23 ` Christian Brauner [this message]
2022-03-29 14:40 ` Christian Brauner
2022-03-29 21:28 ` Linus Torvalds
2022-03-29 20:44 ` aissur0002
2022-03-29 21:02 ` Linus Torvalds
2022-03-29 22:18 ` Linus Torvalds
2022-03-29 22:23 ` Linus Torvalds
2022-03-30 7:47 ` Christian Brauner
2022-03-30 5:21 ` Jason A. Donenfeld
2022-03-30 6:08 ` Linus Torvalds
2022-03-30 6:21 ` Jason A. Donenfeld
2022-03-30 6:28 ` Linus Torvalds
2022-03-30 6:43 ` Linus Torvalds
2022-03-29 23:02 ` Alexey Khoroshilov
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=20220329102347.iu6mlbv5c76ci3j7@wittgenstein \
--to=brauner@kernel.org \
--cc=aissur0002@gmail.com \
--cc=ebiggers@kernel.org \
--cc=khoroshilov@ispras.ru \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®