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] [day] [month] [year] [list]
Message-ID: <87k08qlz8a.fsf@email.froward.int.ebiederm.org>
Date:   Wed, 06 Jul 2022 16:15:17 -0500
From:   "Eric W. Biederman" <ebiederm@...ssion.com>
To:     Sven Schnelle <svens@...ux.ibm.com>
Cc:     Oleg Nesterov <oleg@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ptrace: fix clearing of JOBCTL_TRACED in
 ptrace_unfreeze_traced()

Sven Schnelle <svens@...ux.ibm.com> writes:

> CI reported the following splat while running the strace testsuite:
>
> [ 3976.640309] WARNING: CPU: 1 PID: 3570031 at kernel/ptrace.c:272 ptrace_check_attach+0x12e/0x178
> [ 3976.640391] CPU: 1 PID: 3570031 Comm: strace Tainted: G           OE     5.19.0-20220624.rc3.git0.ee819a77d4e7.300.fc36.s390x #1
> [ 3976.640410] Hardware name: IBM 3906 M04 704 (z/VM 7.1.0)
> [ 3976.640452] Call Trace:
> [ 3976.640454]  [<00000000ab4b645a>] ptrace_check_attach+0x132/0x178
> [ 3976.640457] ([<00000000ab4b6450>] ptrace_check_attach+0x128/0x178)
> [ 3976.640460]  [<00000000ab4b6cde>] __s390x_sys_ptrace+0x86/0x160
> [ 3976.640463]  [<00000000ac03fcec>] __do_syscall+0x1d4/0x200
> [ 3976.640468]  [<00000000ac04e312>] system_call+0x82/0xb0
> [ 3976.640470] Last Breaking-Event-Address:
> [ 3976.640471]  [<00000000ab4ea3c8>] wait_task_inactive+0x98/0x190
>
> This is because JOBCTL_TRACED is set, but the task is not in TASK_TRACED
> state. Caused by ptrace_unfreeze_traced() which does:
>
> task->jobctl &= ~TASK_TRACED
>
> but it should be:
>
> task->jobctl &= ~JOBCTL_TRACED


That would definitely do it.  I had to think about it for a few minutes
to see how it explains some of the stranger behavior but it explains
all of the funny behavior I have seen.

Thank you for tracking this down.

The fact the original bug report was on s390 had me somehow thinking
this was s390 only.

I will double check everything get this in linux-next and then send this
to Linus.

Eric


> Fixes: 31cae1eaae4f ("sched,signal,ptrace: Rework TASK_TRACED, TASK_STOPPED state")
> Signed-off-by: Sven Schnelle <svens@...ux.ibm.com>
> ---
>  kernel/ptrace.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> index 156a99283b11..1893d909e45c 100644
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -222,7 +222,7 @@ static void ptrace_unfreeze_traced(struct task_struct *task)
>  	if (lock_task_sighand(task, &flags)) {
>  		task->jobctl &= ~JOBCTL_PTRACE_FROZEN;
>  		if (__fatal_signal_pending(task)) {
> -			task->jobctl &= ~TASK_TRACED;
> +			task->jobctl &= ~JOBCTL_TRACED;
>  			wake_up_state(task, __TASK_TRACED);
>  		}
>  		unlock_task_sighand(task, &flags);

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ