All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>,
	Jordy Zomer <jordy@jordyzomer.github.io>,
	linux-mm@kvack.org, Dmitry Vyukov <dvyukov@google.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	David Hildenbrand <david@redhat.com>,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] mm/secretmem: Avoid letting secretmem_users drop to zero
Date: Thu, 21 Oct 2021 20:39:03 -0700	[thread overview]
Message-ID: <202110212037.E18CD404@keescook> (raw)
In-Reply-To: <20211021195311.6058b90f573641542605dae4@linux-foundation.org>

On Thu, Oct 21, 2021 at 07:53:11PM -0700, Andrew Morton wrote:
> On Thu, 21 Oct 2021 08:40:46 -0700 Kees Cook <keescook@chromium.org> wrote:
> 
> > Quoting Dmitry: "refcount_inc() needs to be done before fd_install().
> > After fd_install() finishes, the fd can be used by userspace and we can
> > have secret data in memory before the refcount_inc().
> > 
> > A straightforward mis-use where a user will predict the returned fd
> > in another thread before the syscall returns and will use it to store
> > secret data is somewhat dubious because such a user just shoots themself
> > in the foot.
> > 
> > But a more interesting mis-use would be to close the predicted fd and
> > decrement the refcount before the corresponding refcount_inc, this way
> > one can briefly drop the refcount to zero while there are other users
> > of secretmem."
> > 
> > Move fd_install() after refcount_inc().
> 
> I added cc:stable.  Or doesn't the benefit/risk ratio justify that?

I hadn't because commit 110860541f44 ("mm/secretmem: use refcount_t
instead of atomic_t") wasn't, and this would build on top of it.

I think the exposure is very small in both places, so probably best to
avoid the churn, but I'm not _opposed_ to it.

-- 
Kees Cook

  reply	other threads:[~2021-10-22  3:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-21 15:40 [PATCH] mm/secretmem: Avoid letting secretmem_users drop to zero Kees Cook
2021-10-21 15:48 ` Dmitry Vyukov
2021-10-21 15:50 ` David Hildenbrand
2021-10-21 16:47 ` Jordy Zomer
2021-10-22  2:53 ` Andrew Morton
2021-10-22  3:39   ` Kees Cook [this message]
2021-10-22  7:09     ` Mike Rapoport

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=202110212037.E18CD404@keescook \
    --to=keescook@chromium.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=dvyukov@google.com \
    --cc=jordy@jordyzomer.github.io \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rppt@kernel.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.