linux-kernel - arch/tile/kernel/hardwall.c:do_hardwall_trap unsafe/wrong usage of ->sighand

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:	Thu, 21 Apr 2011 21:03:32 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Matt Fleming <matt@...sole-pimps.org>,
	Chris Metcalf <cmetcalf@...era.com>
Cc:	Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"H. Peter Anvin" <hpa@...or.com>,
	Matt Fleming <matt.fleming@...ux.intel.com>
Subject: arch/tile/kernel/hardwall.c:do_hardwall_trap unsafe/wrong usage of
	->sighand

On 04/18, Oleg Nesterov wrote:
>
> On 04/16, Matt Fleming wrote:
> >
> > 	3. I suspect most people find the rules of ->sighand pretty
> > 	confusing. Just look at
> >
> > 		arch/tile/kernel/hardwall.c:do_hardwall_trap()
> >
> > 	the use of siglock there looks buggy to me.
>
> Indeed, I agree. It shouldn't use __group_send_sig_info() at all.
> I'll send the patch. Nobody outside of signal code should play with
> ->sighand, this is almost always wrong.

Hmm. It turns out, I can't make the patch because I do not understand
what this code tries to do.

hardwall_activate() adds the thread to hardwall_list, but do_hardwall_trap()
sends the signal to the whole process. I know nothing about arch/tile and
probably this is correct, but could you confirm this?

Note that SIGILL can be delivered to another thread in the thread-group, is
it correct?

Also. Is it supposed that SIGILL can have a hanlder or can be blocked, or
it should always kill the whole thread group?

I think we need the patch below, assuming that SIGILL should be sent to
the single thread and it is fine to have a handler for SIGILL.

Oleg.

--- sigprocmask/arch/tile/kernel/hardwall.c~1_sighand	2011-04-06 21:33:42.000000000 +0200
+++ sigprocmask/arch/tile/kernel/hardwall.c	2011-04-21 20:56:36.000000000 +0200
@@ -268,12 +268,10 @@ void __kprobes do_hardwall_trap(struct p
 	found_processes = 0;
 	list_for_each_entry(p, &rect->task_head, thread.hardwall_list) {
 		BUG_ON(p->thread.hardwall != rect);
-		if (p->sighand) {
+		if (!(p->flags & PF_EXITING)) {
 			found_processes = 1;
 			pr_notice("hardwall: killing %d\n", p->pid);
-			spin_lock(&p->sighand->siglock);
-			__group_send_sig_info(info.si_signo, &info, p);
-			spin_unlock(&p->sighand->siglock);
+			do_send_sig_info(info.si_signo, &info, p, false);
 		}
 	}
 	if (!found_processes)

--
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/