linux-kernel - Re: Procfs race condition bug

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] [day] [month] [year] [list]

Message-ID: <87fvi925eg.fsf@x220.int.ebiederm.org>
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/