netdev - Re: [Lguest] [PATCH 4/5] lguest: use KVM hypercalls

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: <m18wm2rqy6.fsf@fess.ebiederm.org>
Date:	Wed, 15 Apr 2009 06:23:29 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Patrick McHardy <kaber@...sh.net>,
	Matias Zabaljauregui <zabaljauregui@...il.com>, odie@...aau.dk,
	Rusty Russell <rusty@...tcorp.com.au>, lguest@...abs.org,
	virtualization@...ts.osdl.org,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	Christian Borntraeger <borntraeger@...ibm.com>
Subject: Re: [Lguest] [PATCH 4/5] lguest: use KVM hypercalls

Herbert Xu <herbert@...dor.apana.org.au> writes:

> On Wed, Apr 15, 2009 at 04:36:10PM +0800, Herbert Xu wrote:
>> 
>> Let me whip up a patch.
>
> tun: Fix sk_sleep races when attaching/detaching
>
> As the sk_sleep wait queue actually lives in tfile, which may be
> detached from the tun device, bad things will happen when we use
> sk_sleep after detaching.
>
> Since the tun device is the persistent data structure here (when
> requested by the user), it makes much more sense to have the wait
> queue live there.  There is no reason to have it in tfile at all
> since the only time we can wait is if we have a tun attached.
> In fact we already have a wait queue in tun_struct, so we might
> as well use it.

There is a GIGANTIC reason to have the wait queue on tfile.

If you open a file, and do ip link del tapN you can still
be blocked waiting in poll.

The problem is specifically free_poll_entry, where we call
remove_wait_queue and fput without calling any file methods.
So all of this happens without struct tun_file's count being
elevated.  Which means tun_net_uninit can detach before we get
off of the stupid poll wait queue.

As documented in:

commit b2430de37ef0bc0799ffba7b5219d38ca417eb76
Author: Eric W. Biederman <ebiederm@...ssion.com>
Date:   Tue Jan 20 11:03:21 2009 +0000

    tun: Move read_wait into tun_file
    
    The poll interface requires that the waitqueue exist while the struct
    file is open.  In the rare case when a tun device disappears before
    the tun file closes we fail to provide this property, so move
    read_wait.
    
    This is safe now that tun_net_xmit is atomic with tun_detach.
    
    Signed-off-by: Eric W. Biederman <ebiederm@...stanetworks.com>
    Signed-off-by: David S. Miller <davem@...emloft.net>



I specifically moved the wait queue out of tun struct to avoid this
race.

I will see about getting the vfs to do something saner in my generic
revoke work.  But for 2.6.30 we have to live with the nasties that
are there.

Nacked-by: "Eric W. Biederman" <ebiederm@...ssion.com>

Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html