linux-kernel - Re: fs: uninterruptible hang in handle

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFzM=5wZmQJx7ShxjisY=iGZfu1546qFxhDZFx-MsaAMeg@mail.gmail.com>
Date:	Wed, 2 Mar 2016 09:03:01 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrea Arcangeli <aarcange@...hat.com>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	syzkaller <syzkaller@...glegroups.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>
Subject: Re: fs: uninterruptible hang in handle_userfault

On Wed, Mar 2, 2016 at 6:55 AM, Andrea Arcangeli <aarcange@...hat.com> wrote:
>
> Running page faults that late in the exit path with signal disabled
> was frankly unexpected.

I agree that it's less than wonderful.

>        Apparently it's not just
> PF_EXITING that prevents SIGKILL to reach handle_userfault(). The
> below change still didn't allow to kill the task:
>
> +       exit_futex(tsk); /* run before setting PF_EXITING */
>         exit_signals(tsk);  /* sets PF_EXITING */

It's not just "exit_futex()" (what is that? I assume you mean
exit_robust_list()) that triggers the problem, it's also the

        put_user(0, tsk->clear_child_tid);

in mm_release().

So it's not just about futexes.

The might be other final user space accesses lurking too that I didn't
even think about.

Anyway, I committed (a) as the safest version with the least side
effects. If people think some more about this and come up with
solutions how to avoid these kinds of "very late user space accesses"
cleanly, I think that would be great.

            Linus