From: Al Viro <viro@zeniv.linux.org.uk>
To: Thiago Macieira <thiago.macieira@intel.com>
Cc: linux-fsdevel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: fcntl(F_DUPFD) causing apparent file descriptor table corruption
Date: Tue, 19 May 2020 23:04:09 +0100 [thread overview]
Message-ID: <20200519220409.GT23230@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200519214520.GS23230@ZenIV.linux.org.uk>
On Tue, May 19, 2020 at 10:45:20PM +0100, Al Viro wrote:
> The obvious fix would be to turn cpy and set into size_t - as in
> ed fs/file.c <<'EOF'
> /copy_fdtable/+2s/unsigned int/size_t/
> w
> q
> EOF
>
> On size_t overflow you would've failed allocation before getting to that
> point - see sysctl_nr_open_max initializer. Overflow in alloc_fdtable()
> (nr is unsigned int there) also can't happen, AFAICS - the worst you
> can get is 1U<<31, which will fail sysctl_nr_open comparison.
>
> I really wonder about the missing couple of syscalls in your strace, though;
> could you verify that they _are_ missing and see what the fix above does to
> your testcase?
Anyway, whether it's all there is to your reproducers or not, the bug
is obvious; I've pushed the following into #fixes.
commit 784233a6d4a56f1d0e6e4490fbf38d3cce5742ec
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Tue May 19 17:48:52 2020 -0400
fix multiplication overflow in copy_fdtable()
cpy and set really should be size_t; we won't get an overflow on that,
since sysctl_nr_open can't be set above ~(size_t)0 / sizeof(void *),
so nr that would've managed to overflow size_t on that multiplication
won't get anywhere near copy_fdtable() - we'll fail with EMFILE
before that.
Cc: stable@kernel.org # v2.6.25+
Fixes: 9cfe015aa424 (get rid of NR_OPEN and introduce a sysctl_nr_open)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
diff --git a/fs/file.c b/fs/file.c
index c8a4e4c86e55..abb8b7081d7a 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -70,7 +70,7 @@ static void copy_fd_bitmaps(struct fdtable *nfdt, struct fdtable *ofdt,
*/
static void copy_fdtable(struct fdtable *nfdt, struct fdtable *ofdt)
{
- unsigned int cpy, set;
+ size_t cpy, set;
BUG_ON(nfdt->max_fds < ofdt->max_fds);
next prev parent reply other threads:[~2020-05-19 22:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-19 21:03 fcntl(F_DUPFD) causing apparent file descriptor table corruption Thiago Macieira
2020-05-19 21:45 ` Al Viro
2020-05-19 22:04 ` Al Viro [this message]
2020-05-19 22:18 ` Thiago Macieira
2020-05-19 22:28 ` Al Viro
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=20200519220409.GT23230@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=thiago.macieira@intel.com \
--cc=torvalds@linux-foundation.org \
/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.