| Submitter | David Woodhouse |
|---|---|
| Date | April 23, 2009, 5:04 p.m. |
| Message ID | <1240506258.15245.11.camel@macbook.infradead.org> |
| Download | mbox | patch |
| Permalink | /patch/26375/ |
| State | Accepted |
| Delegated to: | David Miller |
| Headers | show |
Comments
From: David Woodhouse <dwmw2@infradead.org> Date: Thu, 23 Apr 2009 18:04:18 +0100 > When creating a certain types of VPN, NetworkManager will first attempt > to find an available tun device by iterating through 'vpn%d' until it > finds one that isn't already busy. Then it'll set that to be persistent > and owned by the otherwise unprivileged user that the VPN dæmon itself > runs as. > > There's a race condition here -- during the period where the vpn%d > device is created and we're waiting for the VPN dæmon to actually > connect and use it, if we try to create _another_ device we could end up > re-using the same one -- because trying to open it again doesn't get > -EBUSY as it would while it's _actually_ busy. > > So solve this, we add an IFF_TUN_EXCL flag which causes tun_set_iff() to > fail if it would be opening an existing persistent tundevice -- so that > we can make sure we're getting an entirely _new_ device. > > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Applied to net-next-2.6, thanks David. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch
diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 16716ae..0488380 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -867,6 +867,8 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) dev = __dev_get_by_name(net, ifr->ifr_name); if (dev) { + if (ifr->ifr_flags & IFF_TUN_EXCL) + return -EBUSY; if ((ifr->ifr_flags & IFF_TUN) && dev->netdev_ops == &tun_netdev_ops) tun = netdev_priv(dev); else if ((ifr->ifr_flags & IFF_TAP) && dev->netdev_ops == &tap_netdev_ops) diff --git a/include/linux/if_tun.h b/include/linux/if_tun.h index 049d6c9..915ba57 100644 --- a/include/linux/if_tun.h +++ b/include/linux/if_tun.h @@ -55,6 +55,7 @@ #define IFF_NO_PI 0x1000 #define IFF_ONE_QUEUE 0x2000 #define IFF_VNET_HDR 0x4000 +#define IFF_TUN_EXCL 0x8000 /* Features for GSO (TUNSETOFFLOAD). */ #define TUN_F_CSUM 0x01 /* You can hand me unchecksummed packets. */
When creating a certain types of VPN, NetworkManager will first attempt to find an available tun device by iterating through 'vpn%d' until it finds one that isn't already busy. Then it'll set that to be persistent and owned by the otherwise unprivileged user that the VPN dæmon itself runs as. There's a race condition here -- during the period where the vpn%d device is created and we're waiting for the VPN dæmon to actually connect and use it, if we try to create _another_ device we could end up re-using the same one -- because trying to open it again doesn't get -EBUSY as it would while it's _actually_ busy. So solve this, we add an IFF_TUN_EXCL flag which causes tun_set_iff() to fail if it would be opening an existing persistent tundevice -- so that we can make sure we're getting an entirely _new_ device. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>