All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Kees Cook <keescook@chromium.org>,
	Dmitry Vyukov <dvyukov@google.com>,
	syzbot <syzbot+b904a1de3ec43711eba5@syzkaller.appspotmail.com>,
	Jordy Zomer <jordy@pwning.systems>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] WARNING: refcount bug in sys_memfd_secret
Date: Sun, 24 Oct 2021 18:31:30 +0300	[thread overview]
Message-ID: <YXV8Uq17fjBVvQNn@kernel.org> (raw)
In-Reply-To: <YXU7/iRjf9v77gon@casper.infradead.org>

On Sun, Oct 24, 2021 at 11:57:02AM +0100, Matthew Wilcox wrote:
> On Sun, Oct 24, 2021 at 08:37:59AM +0300, Mike Rapoport wrote:
> > On Sat, Oct 23, 2021 at 11:46:18PM +0100, Matthew Wilcox wrote:
> > > On Sat, Oct 23, 2021 at 10:03:11AM -0700, Kees Cook wrote:
> > > > On October 23, 2021 8:27:28 AM PDT, Mike Rapoport <rppt@kernel.org> wrote:
> > > > >and my first reaction was to send a revert the untested commit 110860541f44
> > > > >("mm/secretmem: use refcount_t instead of atomic_t"). 
> > > 
> > > I think you should.  This isn't a real problem. 
> > 
> > Do you mean that creation of 4 billion of file descriptors is not feasible?
> 
> On a sufficiently large machine, it is.  But then we have the same
> problem with other atomic_t.  If you really care, just check whether
> secretmem_users has gone negative, and return -ENFILE.  It doesn't
> even have to be all that exact; you've got 2 billion values of slop
> to use before you hit the wrap from negative to 0 which is the actual
> problem.
> 
> ie this:
> 
> +++ b/mm/secretmem.c
> @@ -203,6 +203,8 @@ SYSCALL_DEFINE1(memfd_secret, unsigned int, flags)
> 
>         if (flags & ~(SECRETMEM_FLAGS_MASK | O_CLOEXEC))
>                 return -EINVAL;
> +       if (atomic_read(&secretmem_users) < 0)
> +               return -ENFILE;

So you suggest to prevent creation of the file descriptor to ensure there
is no overflow of secretmem_users. I don't feel it's a clean and elegant
solution.

> 
>         fd = get_unused_fd_flags(flags & O_CLOEXEC);
>         if (fd < 0)
> 
> 
> Also, why does secretmem depend on !EMBEDDED?

There was a request from tiny-config maintainers to keep this code outside
tiny-config and the best option I could find to make secretmem depend on
!EMBEDDED.

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2021-10-24 15:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-22 15:02 [syzbot] WARNING: refcount bug in sys_memfd_secret syzbot
2021-10-22 15:07 ` Dmitry Vyukov
2021-10-22 16:25   ` Jordy Zomer
2021-10-22 16:29     ` Dmitry Vyukov
2021-10-22 16:39       ` Jordy Zomer
2021-10-23 15:27   ` Mike Rapoport
2021-10-23 17:03     ` Kees Cook
2021-10-23 22:46       ` Matthew Wilcox
2021-10-24  5:37         ` Mike Rapoport
2021-10-24  7:07           ` Dmitry Vyukov
2021-10-24 10:57           ` Matthew Wilcox
2021-10-24 15:31             ` Mike Rapoport [this message]
2021-10-23 12:02 ` syzbot
2021-10-23 22:31 ` syzbot
2021-11-24 13:47 ` 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=YXV8Uq17fjBVvQNn@kernel.org \
    --to=rppt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=dvyukov@google.com \
    --cc=jordy@pwning.systems \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=syzbot+b904a1de3ec43711eba5@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=willy@infradead.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.