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: <1181255068.14818.77.camel@localhost.localdomain>
Date:	Fri, 08 Jun 2007 08:24:27 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Satoru Takeuchi <takeuchi_satoru@...fujitsu.com>,
	Roland McGrath <roland@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...sign.ru>
Subject: Re: [BUG] ptraced process waiting on syscall may return kernel
	internal errnos

On Thu, 2007-06-07 at 08:54 -0700, Linus Torvalds wrote:
> 
> On Thu, 7 Jun 2007, Satoru Takeuchi wrote:
> > 
> > I tested your patch and my problem didn't occur again, so it seems to my
> > this case at least.
> 
> Ok. I applied Roland's slightly bigger patch instead, since Ben and Paul
> pointed out that some kernel threads depend on dequeue_signal clearing the 
> bit. You might want to test that one too (or just get current git), just 
> in case there are any differences in behaviour (not bloody likely, but 
> still..)

Looks good to me. Do you think we need to do something about the DRM
notifier thingy too ? Or just let the code as-is, that is use the
notifier/mask (if any) of the task doing the dequeue_signal() ? I don't
see anybody insane enough to use signalfd read() with the DRM lock held
but who knows ...

Oh and Roland patch doesn't prevent signalfd() from stealing synchronous
signals such as SIGSEGV etc... which I think would result in random
behaviour.... do you want a patch for that or we just consider it broken
API usage and let it as it is ?

Cheers,
Ben.

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