All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Kees Cook <keescook@chromium.org>,
	Uladzislau Rezki <urezki@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Yu Zhao <yuzhao@google.com>,
	dev@der-flo.net, Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-perf-users@vger.kernel.org, linux-mm@kvack.org,
	linux-hardening@vger.kernel.org, linux-arch@vger.kernel.org
Subject: [PATCH 0/3] x86/dumpstack: Inline copy_from_user_nmi()
Date: Fri, 16 Sep 2022 06:59:51 -0700	[thread overview]
Message-ID: <20220916135953.1320601-1-keescook@chromium.org> (raw)

Hi,

This fixes a find_vmap_area() deadlock. The main fix is patch 2, repeated here:

    The check_object_size() helper under CONFIG_HARDENED_USERCOPY is
    designed to skip any checks where the length is known at compile time as
    a reasonable heuristic to avoid "likely known-good" cases. However, it can
    only do this when the copy_*_user() helpers are, themselves, inline too.

    Using find_vmap_area() requires taking a spinlock. The check_object_size()
    helper can call find_vmap_area() when the destination is in vmap memory.
    If show_regs() is called in interrupt context, it will attempt a call to
    copy_from_user_nmi(), which may call check_object_size() and then
    find_vmap_area(). If something in normal context happens to be in the
    middle of calling find_vmap_area() (with the spinlock held), the interrupt
    handler will hang forever.

    The copy_from_user_nmi() call is actually being called with a fixed-size
    length, so check_object_size() should never have been called in the
    first place. In order for check_object_size() to see that the length is
    a fixed size, inline copy_from_user_nmi(), as already done with all the
    other uaccess helpers.

    Reported-by: Yu Zhao <yuzhao@google.com>
    Link: https://lore.kernel.org/all/CAOUHufaPshtKrTWOz7T7QFYUNVGFm0JBjvM700Nhf9qEL9b3EQ@mail.gmail.com
    Reported-by: dev@der-flo.net

Patch 1 is a refactor for patch 2, and patch 3 should make sure we avoid
future deadlocks.

Thanks,

-Kees


Kees Cook (3):
  x86/uaccess: Move nmi_uaccess_okay() into uaccess.h
  x86/dumpstack: Inline copy_from_user_nmi()
  usercopy: Add find_vmap_area_try() to avoid deadlocks

 arch/x86/events/core.c          |  1 -
 arch/x86/include/asm/tlbflush.h |  3 --
 arch/x86/include/asm/uaccess.h  |  5 ++--
 arch/x86/kernel/dumpstack.c     |  4 +--
 arch/x86/lib/Makefile           |  2 +-
 arch/x86/lib/usercopy.c         | 52 ---------------------------------
 include/asm-generic/tlb.h       |  9 ------
 include/linux/uaccess.h         | 50 +++++++++++++++++++++++++++++++
 include/linux/vmalloc.h         |  1 +
 kernel/trace/bpf_trace.c        |  2 --
 mm/usercopy.c                   | 11 ++++++-
 mm/vmalloc.c                    | 11 +++++++
 12 files changed, 78 insertions(+), 73 deletions(-)
 delete mode 100644 arch/x86/lib/usercopy.c

-- 
2.34.1


             reply	other threads:[~2022-09-16 14:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-16 13:59 Kees Cook [this message]
2022-09-16 13:59 ` [PATCH 1/3] x86/uaccess: Move nmi_uaccess_okay() into uaccess.h Kees Cook
2022-09-16 13:59 ` [PATCH 2/3] x86/dumpstack: Inline copy_from_user_nmi() Kees Cook
2022-09-16 13:59 ` [PATCH 3/3] usercopy: Add find_vmap_area_try() to avoid deadlocks Kees Cook
2022-09-16 14:46   ` Matthew Wilcox
2022-09-16 15:09     ` Kees Cook
2022-09-16 19:15       ` Matthew Wilcox
2022-09-19  8:29         ` Uladzislau Rezki
2022-09-16 17:29   ` Uladzislau Rezki
2022-09-16 19:57 ` [PATCH 0/3] x86/dumpstack: Inline copy_from_user_nmi() Andrew Morton
2022-09-19 14:46   ` Peter Zijlstra
2022-09-19 19:26     ` Kees Cook
2022-09-17  2:20 ` Yu Zhao

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=20220916135953.1320601-1-keescook@chromium.org \
    --to=keescook@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=dev@der-flo.net \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=urezki@gmail.com \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    --cc=yuzhao@google.com \
    /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.