From: Oleg Nesterov <oleg@redhat.com>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Michal Hocko <mhocko@suse.com>, linux-mm <linux-mm@kvack.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Peter Xu <peterx@redhat.com>, Mike Rapoport <rppt@linux.ibm.com>,
Jann Horn <jannh@google.com>, Jason Gunthorpe <jgg@mellanox.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [BUG] kernel BUG at fs/userfaultfd.c:385 after 04f5866e41fb
Date: Mon, 19 Aug 2019 14:48:33 +0200 [thread overview]
Message-ID: <20190819124832.GA15044@redhat.com> (raw)
In-Reply-To: <3b521a8c-586f-251e-f486-d71ff094b8e9@huawei.com>
Kefeng, et al, sorry I am travelling till the next monday, can't even
open my laptop too often.
On 08/16, Kefeng Wang wrote:
>
> The patch do fix the UAF and avoid panic, and it doesn't seem to cause new issue,
> even if there are some another issue, it can be fixed later :)
Yes... but if we want a hot fix without any understanding why does it
help in this particular case we can simply add mmget_still_valid() into
handle_userfault(), I am almost sure this should equally "fix" (hide) the
problem.
But to clarify, let me repeat that I still think the patch I sent makes
sense anyway; __handle_mm_fault() is possible even after do_coredump()
sets mm->core_state and after userfaultfd_unregister().
> >> [ 67.430243] RIP: 0010:copy_user_handle_tail+0x2/0x10
> >> [ 67.431586] Code: c3 0f 1f 80 00 00 00 00 66 66 90 83 fa 40 0f 82 70 ff ff ff 89 d1 f3 a4 31 c0 66 66 90 c3 66 2e 0f 1f 84 00 00 00 00 00 89 d1 <f3> a4 89 c8 66 66 90 c3 66 0f 1f 44 00 00 66 66 90 83 fa 08 0f 82
> >> [ 67.436978] RSP: 0018:ffff8883c4e8f908 EFLAGS: 00010246
> >> [ 67.438743] RAX: 0000000000000001 RBX: 0000000020ffd000 RCX: 0000000000001000
> >> [ 67.441101] RDX: 0000000000001000 RSI: 0000000020ffd000 RDI: ffff8883c0aa4000
> >> [ 67.442865] RBP: 0000000000001000 R08: ffffed1078154a00 R09: 0000000000000000
> >> [ 67.444534] R10: 0000000000000200 R11: ffffed10781549ff R12: ffff8883c0aa4000
> >> [ 67.446216] R13: ffff8883c6096000 R14: ffff88837721f838 R15: ffff8883c6096000
> >> [ 67.448388] _copy_from_user+0xa1/0xd0
> >> [ 67.449655] mcopy_atomic+0xb3d/0x1380
> >> [ 67.450991] ? lock_downgrade+0x3a0/0x3a0
> >> [ 67.452337] ? mm_alloc_pmd+0x130/0x130
> >> [ 67.453618] ? __might_fault+0x7d/0xe0
> >> [ 67.454980] userfaultfd_ioctl+0x14a2/0x1c30
> >
> > This must not be called after __fput(). So I think there is something else,
> > may by just an unbalanced userfaultfd_ctx_put(). I dunno, I know nothing
> > about usefaultfd.
>
> There are different processes, maybe some concurrency problems.
and this is what I think we need to understand...
> > It would be nice to understand what this reproducer does...
>
> I tried strace -f the reproducer, but can't find any useful info.
Could you send me the output of strace -f ? Not sure it will help and
again, I am not sure I will have a chance to read it this week.
Perhaps it is possible to translate this test-case to C somehow?
Oleg.
next prev parent reply other threads:[~2019-08-19 12:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-13 9:08 [BUG] kernel BUG at fs/userfaultfd.c:385 after 04f5866e41fb Kefeng Wang
2019-08-14 13:53 ` Michal Hocko
2019-08-14 14:45 ` Kefeng Wang
2019-08-14 15:10 ` Oleg Nesterov
2019-08-14 15:41 ` Oleg Nesterov
2019-08-15 2:21 ` Kefeng Wang
2019-08-15 9:54 ` Oleg Nesterov
2019-08-16 10:37 ` Kefeng Wang
2019-08-19 12:48 ` Oleg Nesterov [this message]
2019-08-19 16:05 ` Andrea Arcangeli
2019-08-20 15:59 ` Oleg Nesterov
2019-08-20 16:15 ` Andrea Arcangeli
[not found] ` <73d7b5b1-a88c-5fca-ba16-be214c2524a4@I-love.SAKURA.ne.jp>
2019-08-20 16:09 ` Oleg Nesterov
2019-08-20 16:02 ` [PATCH] userfaultfd_release: always remove uffd flags and clear vm_userfaultfd_ctx Oleg Nesterov
2019-08-20 16:05 ` Andrea Arcangeli
2019-08-21 0:53 ` Kefeng Wang
2019-08-27 16:33 ` [BUG] kernel BUG at fs/userfaultfd.c:385 after 04f5866e41fb Oleg Nesterov
2019-08-27 17:14 ` Andrea Arcangeli
2019-08-28 14:25 ` Oleg Nesterov
2019-08-29 12:05 ` Andrea Arcangeli
2019-08-30 16:49 ` Oleg Nesterov
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=20190819124832.GA15044@redhat.com \
--to=oleg@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=jannh@google.com \
--cc=jgg@mellanox.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=peterx@redhat.com \
--cc=rppt@linux.ibm.com \
--cc=wangkefeng.wang@huawei.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.