netdev - Re: Problem with tun driver

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]

Date:	Thu, 16 Sep 2010 06:16:32 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Martín Ferrari <martin.ferrari@...il.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: Problem with tun driver

Martín Ferrari <martin.ferrari@...il.com> writes:

> (copying Eric as he seems to have been writing patches for tun to work
> with netns)
>
> Hello,
>
> I am seeing a strange behaviour with the TUN driver when using it
> inside a network name space, hope that somebody can help me...
>
> I still couldn' t reproduce this problem outside of my program, so it
> complicates things more. What I am doing is creating a tap device,
> moving it into a namespace and then passing the filedescriptor to
> another process which in turn starts reading from it.
>
> From strace I see that many reads succeed (Ipv6 autoconfig and arp
> requests), and at some point, read returns EBADF. I don't see the
> other processes doing anything suspicious on it at the same time. From
> reading the kernel sources, it seems to be failing the call to
> tun_get(), but I don' t understand how that could be happening...

Is it possible all of the processes in the network namespace you have
passed the tun dev into are dying, and thus destroying the network
namespace the tun dev is in?

It sounds like you are dealing with the network namespace death case,
or that someone is closing your filedescriptor on you.

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