linux-kernel - Re: Fix signalfd interaction with thread-private signals

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: <alpine.LFD.0.98.0706221540430.3593@woody.linux-foundation.org>
Date:	Fri, 22 Jun 2007 15:47:12 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
cc:	Oleg Nesterov <oleg@...sign.ru>,
	Davide Libenzi <davidel@...ilserver.org>,
	Nicholas Miell <nmiell@...cast.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Fix signalfd interaction with thread-private signals



On Sat, 23 Jun 2007, Benjamin Herrenschmidt wrote:
> 
> > 
> > It does exactly so, please note this chunk
> > 
> >  @@ -330,7 +339,7 @@ asmlinkage long sys_signalfd(int ufd, si
> > 
> >                  init_waitqueue_head(&ctx->wqh);
> >                  ctx->sigmask = sigmask;
> >  -               ctx->tsk = current;
> >  +               ctx->tsk = current->group_leader;
> > 
> > > It might well be that signalfd's concept of context is wrong in the
> > > first place and it should be attached to processes rather than threads
> > > and that made more explicit in the first place...
> 
> Yup, looks like I was looking at a wrong patch... I think it's the right
> thing to do indeed.

Quite frankly, it strikes me that if we want to do this, then we shouldn't 
save the _process_ information at all, we should save the "sighand" 
instead.

So either we save the process info, or we save the sighand, but saving the 
"group_leader" seems totally bogus. Especially as the group leader can 
change (by execve()).

One thing that strikes me as I look at that function is that the whole 
signalfd thing doesn't seem to do any reference counting. Ie it looks 
totally buggy wrt passing the resulting fd off to somebody else, and then 
exiting in the original process.

What did I miss?

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