linux-kernel - Re: [BUG] ptraced process waiting on syscall may return kernel internal errnos

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]

Message-Id: <20070613230153.7B3034D059F@magilla.localdomain>
Date:	Wed, 13 Jun 2007 16:01:53 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Oleg Nesterov <oleg@...sign.ru>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Satoru Takeuchi <takeuchi_satoru@...fujitsu.com>
Subject: Re: [BUG] ptraced process waiting on syscall may return kernel
	internal errnos

> The freezer is crap... news at 11. Maybe a quick hack would be to let it
> clear sigpending if tsk->mm == NULL but that's ugly. Note that there's
> anything pretty about the freezer anyway...

I think it might be made not too unreasonable by adding a TASK_FROZEN state.
But I am still persuaded by my "hide in the corner" plan.

> Well.. why was it _and_wake() in the first place anyway ? Or do I miss
> something ? Why would we need to wake a thread for which we are removing
> signals ?

The bug was about a case where recalc_sigpending_tsk would set
TIF_SIGPENDING when it hadn't been set before (wants_signal).  It has
nothing to do with the rm_from_queue_full being done there.  It's just a
violation of the necessary rule that when you set TIF_SIGPENDING on another
thread you better call signal_wake_up on it.

> What about something like:
> 
> 			do {
> 				rm_from_queue_full(&mask, &t->pending);
> -				recalc_sigpending_and_wake(t);
> 				t = next_thread(t);
> 			} while (t != current);
> +			recalc_sigpending();

There is no need for the +, just the -.  The calling thread is the one
where know there is certainly no perturbation of behavior due to leaving
TIF_SIGPENDING set rather than clearing it.  It's just going to exit the
syscall and deal with signal state properly on the way out either way.
Doing recalc_sigpending is an unnecessary optimization of the corner case.

> So at the end of the day, easier to test it inside dequeue_signal().

Before completely revamping the whole set of entrypoints to be saner all
around, yes.

Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/