Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 20 Sep 2008 16:27:03 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Maksim Yevmenkin <maksim.yevmenkin@gmail.com>
Cc:        Alexey Shuvaev <shuvaev@physik.uni-wuerzburg.de>, freebsd-current@freebsd.org
Subject:   Re: Interface auto-cloning bug or feature?
Message-ID:  <20080920132703.GG47828@deviant.kiev.zoral.com.ua>
In-Reply-To: <bb4a86c70809191543y7f3d38ex73c48186dfd163c5@mail.gmail.com>
References:  <48D2F942.4070801@FreeBSD.org> <20080919084201.GD44330@wep4035.physik.uni-wuerzburg.de> <48D38DFF.8000803@FreeBSD.org> <20080919203310.GA34131@localhost.my.domain> <bb4a86c70809191543y7f3d38ex73c48186dfd163c5@mail.gmail.com>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
On Fri, Sep 19, 2008 at 03:43:21PM -0700, Maksim Yevmenkin wrote:
> [....]
> 
> >> That what has caused me to look into this issue. You can find patch for
> >> security/vpnc to prevent unbounded interface cloning here:
> >>
> >> http://sobomax.sippysoft.com/~sobomax/vpnc.diff
> >>
> > Ok, the patch prevents interface cloning, but I think it doesn't solve
> > the actual problem.
> > Let's wait for Maksim :)
> 
> ok, how about attached patch. i put it together *very* quickly and
> only gave it a light testing. its for tap(4), because i could compile
> it as a module and tun(4) is compiled into kernel by default, but the
> idea should identical for tun(4). should be even simpler for tun(4)
> because it does not have to deal with 2 kind of devices (i.e. tap and
> vmnet). give it a try, and see if it works. please try both cloning
> paths, i.e.
> 
> 1) cat /dev/tap (/dev/vmnet) with and/or without unit number
> 
> and
> 
> 2) ifconfig tapX (vmnetX) create/destroy
> 
> in the mean time i will prepare something similar for tun(4).
> 
> thanks,
> max

> --- if_tap.c.orig	2008-09-08 17:20:57.000000000 -0700
> +++ if_tap.c	2008-09-19 15:35:02.000000000 -0700
> @@ -94,6 +94,7 @@
>  static int		tapifioctl(struct ifnet *, u_long, caddr_t);
>  static void		tapifinit(void *);
>  
> +static int		tap_clone_lookup(struct cdev **, u_short);
>  static int		tap_clone_create(struct if_clone *, int, caddr_t);
>  static void		tap_clone_destroy(struct ifnet *);
>  static int		vmnet_clone_create(struct if_clone *, int, caddr_t);
> @@ -176,6 +177,28 @@
>  DEV_MODULE(if_tap, tapmodevent, NULL);
>  
>  static int
> +tap_clone_lookup(struct cdev **dev, u_short extra)
> +{
> +	struct tap_softc *tp;
> +
> +	mtx_lock(&tapmtx);
> +	SLIST_FOREACH(tp, &taphead, tap_next) {
> +		mtx_lock(&tp->tap_mtx);
> +		if ((tp->tap_flags & (TAP_OPEN|extra)) == extra) {
> +			*dev = tp->tap_dev;
> +			mtx_unlock(&tp->tap_mtx);
> +			mtx_unlock(&tapmtx);
> +
> +			return (1);
> +		}
> +		mtx_unlock(&tp->tap_mtx);
> +	}
> +	mtx_unlock(&tapmtx);
> +
> +	return (0);
> +}
> +
> +static int
>  tap_clone_create(struct if_clone *ifc, int unit, caddr_t params)
>  {
>  	struct cdev *dev;
> @@ -353,8 +376,18 @@
>  
>  	/* We're interested in only tap/vmnet devices. */
>  	if (strcmp(name, TAP) == 0) {
> +		if (tap_clone_lookup(dev, 0)) {
> +			dev_ref(*dev);
> +			return;
What would prevent two concurrent threads from selecting the same device
there ? First thread could look up the device, unloc tapmtx and be
preempted. Then second thread is put on CPU, do the same selection.
Now you have a problem.

[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEARECAAYFAkjU+iYACgkQC3+MBN1Mb4g78wCfddJKStzNj9xTz79XbtUJ8do0
zqkAoJY/J9EELGG2kCa1Lz++C7/U7Gwg
=t1a/
-----END PGP SIGNATURE-----
help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080920132703.GG47828>