linux-kernel - Re: [PATCH] select: fix sys_select to not leak ERESTARTNOHAND to userspace

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: <Pine.LNX.4.64.0701220758120.32200@woody.linux-foundation.org>
Date:	Mon, 22 Jan 2007 08:03:53 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Neil Horman <nhorman@...driver.com>
cc:	Paolo Ornati <ornati@...twebnet.it>, linux-kernel@...r.kernel.org,
	akpm@...l.org, torvalds@...l.org
Subject: Re: [PATCH] select: fix sys_select to not leak ERESTARTNOHAND to
 userspace

On Mon, 22 Jan 2007, Neil Horman wrote:

> On Mon, Jan 22, 2007 at 02:59:56PM +0100, Paolo Ornati wrote:
> > 
> > the ERESTARTNOHAND thing is handled in arch specific signal code,
> 
> In the signal handling path yes.

Right.

> Not always in the case of select, though.  Check core_sys_select:

No, even in the case of select().

> if (!ret) {
>                 ret = -ERESTARTNOHAND;
>                 if (signal_pending(current))
>                         goto out;
>                 ret = 0;

Since we have "signal_pending(current)" being true, we _know_ that the 
signal handling path will be triggered, so the ERESTARTNOHAND will be 
changed into the appropriate error return (or restart) by the signal 
handling code.

> Its possible for core_sys_select to return ERESTARTNOHAND to sys_select, which
> will in turn (as its currently written), return that value back to user space.

No. Exactly because sys_select() will always return through the system 
call handling path, and that will turn the ERESTARTNOHAND into something 
else.

NOTE! If you use "ptrace()", you may see the internal errors. But that's a 
ptrace-only thing, and may have fooled you into thinking that the actual 
_application_ sees those internal errors. It won't.

Of course, we could have some signal-handling bug here, but if so, it 
would affect a lot more than just select(). Have you actually seen 
ERESTARTNOINTR in the app (not just ptrace?)

		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/