| 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
| ||
|
Date: Wed, 09 Jul 2014 21:40:07 -0700 From: ebiederm@...ssion.com (Eric W. Biederman) To: Alexey Dobriyan <adobriyan@...il.com> Cc: Mike Cardwell <mike.cardwell@...pular.com>, Andrew Morton <akpm@...ux-foundation.org>, Pavel Emelianov <xemul@...allels.com>, Linux Kernel <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>, One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk> Subject: Re: Procfs race condition bug Alexey Dobriyan <adobriyan@...il.com> writes: > [broken email] > > On Wed, Jul 9, 2014 at 3:17 PM, Alexey Dobriyan <adobriyan@...il.com> wrote: >>> I originally posted this two years ago (*) but received no response. >>> I just had a look and the problem still exists on the 3.14 kernel >>> I am currently running. >>> >>> I *think* I've uncovered a race condition bug in procfs. >>> If I attempt to open a file in /proc/net, eg "/proc/net/tcp" >>> it works fine, but if I spawn a POSIX thread and attempt to do it >>> from there, it *usually* fails with a "No such file or directory", >>> but some times succeeds. If I do a system call inside the thread >>> to look up the thread ID and then open "/proc/THREADID/net/tcp" >>> instead, it works fine. >>> >>> There are more details and some example code >>> so you can replicate the problem on a stack overflow question >>> I asked previously here: >>> http://stackoverflow.com/questions/11580020/opening-proc-net-tcp-in-c-from-a-posix-thread-fails-most-of-the-time >>> >>> (*) https://lkml.org/lkml/2012/7/20/331 >> >> Mike, >> >> as was correctly notes on SO, what's happening is that original thread exits >> before spawned thread does open(). >> >> ->lookup >> proc_tgid_net_lookup >> get_proc_task_net >> nsproxy = NULL <== thread is dead >> ENOENT >> >> This was probably broken when /proc/net became symlink: >> >> commit e9720acd728a46cb40daa52c99a979f7c4ff195c >> Author: Pavel Emelyanov <xemul@...nvz.org> >> Date: Fri Mar 7 11:08:40 2008 -0800 >> >> [NET]: Make /proc/net a symlink on /proc/self/net (v3) >> >> >> So, userspace has two solutions: >> 1) original thread doesn't exit too early >> 2) spawned thread uses /proc/$TID >> >> >> So, >> we definitely broke /proc/net/tcp somewhere after netns concept was introduced. >> >> But, >> you'd have very same problem with other /proc files (anything under >> /proc/$PID/). Agreed it is a /proc/$TGID vs /proc/$TID issue. In principle this is fixable by creating a /proc/current symlink that always points to the proc directory for the current thread and then pointing /proc/net and /proc/mounts at it. This is one of those weird cases it so that /proc/net or /proc/mounts resolves may actually break an existing userspace application, because different threads can point at different values. (I very much dislike what the linux pthread support did to /proc/self). I tilted at that windmill once and ran out of steam. While I can write the patch I don't have the energy to test and see if there are any pthread programs that will break if /proc/net points to /proc/current/net instead of /proc/self/net. Frankly new applications should be using netlink and not /proc/net so I personally don't think this is worth fixing for the /proc/net case. Are there real world applications that are broken by the kernel change in behavior? The stackoverflow discussion sounds like it was just an investigation into weird kernel behavior. Eric -- 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/
Powered by blists - more mailing lists