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: <20180726132050.GA32718@redhat.com>
Date:   Thu, 26 Jul 2018 15:20:50 +0200
From:   Oleg Nesterov <oleg@...hat.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, Wen Yang <wen.yang99@....com.cn>,
        majiang <ma.jiang@....com.cn>
Subject: Re: [PATCH 18/20] signal: Add calculate_sigpending()

On 07/23, Eric W. Biederman wrote:
>
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1988,6 +1988,7 @@ static __latent_entropy struct task_struct *copy_process(
>  					  &p->signal->thread_head);
>  		}
>  		attach_pid(p, PIDTYPE_PID);
> +		calculate_sigpending(p);

In theory this looks racy if !CLONE_SIGHAND, please see below

> +void calculate_sigpending(struct task_struct *new)
> +{
> +	/* Have any signals or users of TIF_SIGPENDING been delayed
> +	 * until after fork?
> +	 */
> +	bool pending = (new->jobctl & JOBCTL_PENDING_MASK) ||
> +		PENDING(&new->pending, &new->blocked) ||
> +		PENDING(&new->signal->shared_pending, &new->blocked) ||
> +		freezing(new) || klp_patch_pending(new);

note that we do not hold new->sighand->siglock, but this "new" task is already
visible to find_task_by_vpid/etc; so a new signal can come right after this check,

> +	update_tsk_thread_flag(new, TIF_SIGPENDING, pending);

and then update_tsk_thread_flag() can wrongly clear TIF_SIGPENDING.

Easy to fix, but perhaps we can simply add recalc_sigpending() into
schedule_tail() ? It already does more than just finish_task_switch/etc.

This way we do not need the new helper (which btw can only be used by
copy_process).


Note also that either way you can remove set_tsk_thread_flag(TIF_SIGPENDING)
from ptrace_init_task().

Oleg.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ