All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3.8-rc] tuntap: refuse to re-attach to different tun_struct
Date: Thu, 10 Jan 2013 21:53:59 +0800	[thread overview]
Message-ID: <50EEC7F7.1030905@redhat.com> (raw)
In-Reply-To: <20130110110737.GD13451@redhat.com>

On 01/10/2013 07:07 PM, Michael S. Tsirkin wrote:
> On Thu, Jan 10, 2013 at 06:43:20PM +0800, Jason Wang wrote:
>> On 01/10/2013 06:23 PM, Michael S. Tsirkin wrote:
>>> On Thu, Jan 10, 2013 at 08:59:48AM +0100, Stefan Hajnoczi wrote:
>>>> Multiqueue tun devices support detaching a tun_file from its tun_struct
>>>> and re-attaching at a later point in time.  This allows users to disable
>>>> a specific queue temporarily.
>>>>
>>>> ioctl(TUNSETIFF) allows the user to specify the network interface to
>>>> attach by name.  This means the user can attempt to attach to interface
>>>> "B" after detaching from interface "A".
>>>>
>>>> The driver is not designed to support this so check we are re-attaching
>>>> to the right tun_struct.  Failure to do so may lead to oops.
>>>>
>>>> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
>>>> ---
>>>> This fix is for 3.8-rc.
>>>>
>>>>  drivers/net/tun.c | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>>> index fbd106e..cf6da6e 100644
>>>> --- a/drivers/net/tun.c
>>>> +++ b/drivers/net/tun.c
>>>> @@ -491,6 +491,8 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
>>>>  	err = -EINVAL;
>>>>  	if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
>>>>  		goto out;
>>>> +	if (tfile->detached && tun != tfile->detached)
>>>> +		goto out;
>>>>  
>>>>  	err = -EBUSY;
>>>>  	if (!(tun->flags & TUN_TAP_MQ) && tun->numqueues == 1)
>>>> -- 
>>>> 1.8.0.2
>>> I agree this is a bug but even with this patch, we still allow:
>>>
>>> SETIFF
>>> SETQUEUE (DISABLED)
>>> SETIFF
>>>
>>> Originally the rule always was that repeated setiff calls fail with
>>> EINVAL. We broke that when we set tun to NULL.  It's probably worth
>>> preserving that, even if queue is disabled.  Applying something like the below
>>> instead will address this concern, won't it?
>>>
>>> Note: works with regular userspace but I didn't test
>>> multiqueue userspace. What do you think.
>> Or just fail when tun->detached is not NULL at the beginning of
>> tun_set_iff()?
> Yes that'll also work I think. If you prefer this pls send patch.

Will post a patch, thanks.
>>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>>>
>>> ---
>>>
>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>> index fbd106e..5ec8b08 100644
>>> --- a/drivers/net/tun.c
>>> +++ b/drivers/net/tun.c
>>> @@ -483,7 +483,7 @@ static void tun_detach_all(struct net_device *dev)
>>>  	BUG_ON(tun->numdisabled != 0);
>>>  }
>>>  
>>> -static int tun_attach(struct tun_struct *tun, struct file *file)
>>> +static int tun_attach(struct tun_struct *tun, struct file *file, bool setiff)
>>>  {
>>>  	struct tun_file *tfile = file->private_data;
>>>  	int err;
>>> @@ -492,6 +492,9 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
>>>  	if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
>>>  		goto out;
>>>  
>>> +	if (setiff && tfile->detached)
>>> +		goto out;
>>> +
>>>  	err = -EBUSY;
>>>  	if (!(tun->flags & TUN_TAP_MQ) && tun->numqueues == 1)
>>>  		goto out;
>>> @@ -1561,7 +1564,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
>>>  		if (err < 0)
>>>  			return err;
>>>  
>>> -		err = tun_attach(tun, file);
>>> +		err = tun_attach(tun, file, true);
>>>  		if (err < 0)
>>>  			return err;
>>>  
>>> @@ -1627,7 +1630,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
>>>  		dev->features = dev->hw_features;
>>>  
>>>  		INIT_LIST_HEAD(&tun->disabled);
>>> -		err = tun_attach(tun, file);
>>> +		err = tun_attach(tun, file, true);
>>>  		if (err < 0)
>>>  			goto err_free_dev;
>>>  
>>> @@ -1792,7 +1795,7 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
>>>  		else if (tun_not_capable(tun))
>>>  			ret = -EPERM;
>>>  		else
>>> -			ret = tun_attach(tun, file);
>>> +			ret = tun_attach(tun, file, false);
>>>  	} else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
>>>  		tun = rcu_dereference_protected(tfile->tun,
>>>  						lockdep_rtnl_is_held());
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
> --
> 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


  reply	other threads:[~2013-01-10 13:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-10  7:59 [PATCH 3.8-rc] tuntap: refuse to re-attach to different tun_struct Stefan Hajnoczi
2013-01-10  9:25 ` Jason Wang
2013-01-10 10:23 ` Michael S. Tsirkin
2013-01-10 10:43   ` Jason Wang
2013-01-10 11:07     ` Michael S. Tsirkin
2013-01-10 13:53       ` Jason Wang [this message]
2013-01-10 11:53   ` Stefan Hajnoczi
2013-01-10 22:39 ` David Miller
2013-01-11  1:29   ` Jason Wang
2013-01-11  5:12     ` David Miller
2013-01-11  8:38       ` Jason Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50EEC7F7.1030905@redhat.com \
    --to=jasowang@redhat.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.