From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: arm64 test_user_copy crash on copy_from_user(uptr, kptr, size)
Date: Fri, 26 May 2017 16:40:48 +0100 [thread overview]
Message-ID: <20170526154048.GB22865@leverpostej> (raw)
In-Reply-To: <CAK8P3a1tyU8J4VEWVwLOHWM+of9bnWvm+SXBxkfsZA7yfEei9A@mail.gmail.com>
On Fri, May 26, 2017 at 05:24:47PM +0200, Arnd Bergmann wrote:
> A kselftest run on arm64 on an older 4.4.y stable kernel ran into an
> unexpectedly trapping user space access:
>
> [ 1277.857738] Internal error: Accessing user space memory outside
> uaccess.h routines: 96000045 [#1] PREEMPT SMP
>
> Apparently the same thing happens on x86 as well, and it still happens on
> the latest kernels, see https://bugs.linaro.org/show_bug.cgi?id=3011
>
> The problem here is this test
>
> ret |= test(!copy_from_user(bad_usermem, (char __user *)kmem,
> PAGE_SIZE),
> "illegal reversed copy_from_user passed");
>
> where the destination kernel pointer intentionally points into user space
> memory, while copy_from_user checks the second argument for being
> a valid user space, which it also is not.:
>
> static inline unsigned long __must_check copy_from_user(void *to,
> const void __user *from, unsigned long n)
> {
> unsigned long res = n;
> kasan_check_write(to, n);
>
> if (access_ok(VERIFY_READ, from, n)) {
> check_object_size(to, n, false);
> res = __arch_copy_from_user(to, from, n);
> }
> if (unlikely(res))
> memset(to + (n - res), 0, res);
> return res;
> }
>
> The memset here will now try to clear user space data, and the
> architecture notices that the fault did not come from a proper
> uaccess function.
>
> I think this will only happen when CONFIG_ARM64_PAN,
> X86_SMAP or an equivalent feature on another architecture is
> enabled, otherwise we just do the access anyway. I don't have
> a good idea for avoiding the problem though, other than
> removing the specific test that causes it.
AFAICT, that test was disabled in commit:
f5f893c57e37ca73 ("usercopy: Adjust tests to deal with SMAP/PAN")
... or have I misunderstood?
Thanks,
Mark.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
next prev parent reply other threads:[~2017-05-26 15:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-26 15:24 arm64 test_user_copy crash on copy_from_user(uptr, kptr, size) Arnd Bergmann
2017-05-26 15:40 ` Mark Rutland [this message]
2017-05-26 20:35 ` Arnd Bergmann
2017-05-26 15:41 ` Kees Cook
2017-05-26 20:37 ` Arnd Bergmann
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=20170526154048.GB22865@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox