All of lore.kernel.org
 help / color / mirror / Atom feed
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);
 

  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.