linux-kernel - Re: 5.8-rc*: kernel BUG at kernel/signal.c:1917

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 20 Jul 2020 16:02:24 +0200
From:   Oleg Nesterov <oleg@...hat.com>
To:     peterz@...radead.org
Cc:     Jiri Slaby <jirislaby@...nel.org>,
        Christian Brauner <christian.brauner@...ntu.com>,
        christian@...uner.io, "Eric W. Biederman" <ebiederm@...ssion.com>,
        Linux kernel mailing list <linux-kernel@...r.kernel.org>,
        Mel Gorman <mgorman@...e.de>,
        Dave Jones <davej@...emonkey.org.uk>,
        Paul Gortmaker <paul.gortmaker@...driver.com>
Subject: Re: 5.8-rc*: kernel BUG at kernel/signal.c:1917

On 07/20, Peter Zijlstra wrote:
>
> Also, is there any way to not have ptrace do this?

Well, we need to ensure that even SIGKILL can't wake the tracee up while
debugger plays with its registers/etc.

> How performance
> critical is this ptrace path?

This is a slow path.

We can probably change ptrace_check_attach() to call ptrace_freeze_traced()
after wait_task_inactive(), but I would like to not do this... Because we
actually want to avoid wait_task_inactive() when possible.

Perhaps ptrace_freeze_traced() can __task_rq_lock() to avoid the race with
__schedule() ? No, it reads prev_state before rq_lock().

> Because I really hate having to add code
> to __schedule() to deal with this horrible thing.

Oh yes, I agree.

I have to admit, I do not understand the usage of prev_state in schedule(),
it looks really, really subtle...

Oleg.