netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [Patch net v2] tun: fix a memory leak for tfile->tx_array
@ 2018-01-10 18:51 Cong Wang
  2018-01-11 10:16 ` Jason Wang
  0 siblings, 1 reply; 5+ messages in thread
From: Cong Wang @ 2018-01-10 18:51 UTC (permalink / raw)
  To: netdev; +Cc: dvyukov, Cong Wang, Jason Wang

tfile->tun could be detached before we close the tun fd,
via tun_detach_all(), so it should not be used to check for
tfile->tx_array.

As Jason suggested, we probably have to clean it up
unconditionally, but this requires to check if it is initialized
or not. Currently skb_array_cleanup() doesn't have such a check,
so I check it in the caller, it is ugly but we can always
improve it in net-next.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Fixes: 1576d9860599 ("tun: switch to use skb array for tx")
Cc: Jason Wang <jasowang@redhat.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
 drivers/net/tun.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 4f4a842a1c9c..4c85474ffbaf 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -657,7 +657,7 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
 			    tun->dev->reg_state == NETREG_REGISTERED)
 				unregister_netdevice(tun->dev);
 		}
-		if (tun)
+		if (tfile->tx_array.ring.queue)
 			skb_array_cleanup(&tfile->tx_array);
 		sock_put(&tfile->sk);
 	}
@@ -2851,6 +2851,8 @@ static int tun_chr_open(struct inode *inode, struct file * file)
 
 	sock_set_flag(&tfile->sk, SOCK_ZEROCOPY);
 
+	memset(&tfile->tx_array, 0, sizeof(tfile->tx_array));
+
 	return 0;
 }
 
-- 
2.13.0

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [Patch net v2] tun: fix a memory leak for tfile->tx_array
  2018-01-10 18:51 [Patch net v2] tun: fix a memory leak for tfile->tx_array Cong Wang
@ 2018-01-11 10:16 ` Jason Wang
  2018-01-13 17:31   ` Cong Wang
  0 siblings, 1 reply; 5+ messages in thread
From: Jason Wang @ 2018-01-11 10:16 UTC (permalink / raw)
  To: Cong Wang, netdev; +Cc: dvyukov, Michael S. Tsirkin



On 2018年01月11日 02:51, Cong Wang wrote:
> tfile->tun could be detached before we close the tun fd,
> via tun_detach_all(), so it should not be used to check for
> tfile->tx_array.
>
> As Jason suggested, we probably have to clean it up
> unconditionally, but this requires to check if it is initialized
> or not. Currently skb_array_cleanup() doesn't have such a check,
> so I check it in the caller, it is ugly but we can always
> improve it in net-next.

Rethink about this, looks like I was wrong. The case I mentioned 
previously is

open
attach
detach
close

But during close, we will try to enable tfile through tun_enable_queue() 
in __tun_detach(), which means we can do the cleanup for sure.

It looks to me what is actual missed is the cleanups tun_detach_all(). 
For me the only case that could leak is

open
attach
ip link del link dev tap0
close or another set_iff()

So in this case, clean during close is not sufficient since it could be 
attached to another device.

Thanks

>
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Fixes: 1576d9860599 ("tun: switch to use skb array for tx")
> Cc: Jason Wang <jasowang@redhat.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
>   drivers/net/tun.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 4f4a842a1c9c..4c85474ffbaf 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -657,7 +657,7 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
>   			    tun->dev->reg_state == NETREG_REGISTERED)
>   				unregister_netdevice(tun->dev);
>   		}
> -		if (tun)
> +		if (tfile->tx_array.ring.queue)
>   			skb_array_cleanup(&tfile->tx_array);
>   		sock_put(&tfile->sk);
>   	}
> @@ -2851,6 +2851,8 @@ static int tun_chr_open(struct inode *inode, struct file * file)
>   
>   	sock_set_flag(&tfile->sk, SOCK_ZEROCOPY);
>   
> +	memset(&tfile->tx_array, 0, sizeof(tfile->tx_array));
> +
>   	return 0;
>   }
>   

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Patch net v2] tun: fix a memory leak for tfile->tx_array
  2018-01-11 10:16 ` Jason Wang
@ 2018-01-13 17:31   ` Cong Wang
  2018-01-15  7:07     ` Jason Wang
  0 siblings, 1 reply; 5+ messages in thread
From: Cong Wang @ 2018-01-13 17:31 UTC (permalink / raw)
  To: Jason Wang
  Cc: Linux Kernel Network Developers, Dmitry Vyukov, Michael S. Tsirkin

On Thu, Jan 11, 2018 at 2:16 AM, Jason Wang <jasowang@redhat.com> wrote:
>
> It looks to me what is actual missed is the cleanups tun_detach_all(). For
> me the only case that could leak is
>
> open
> attach
> ip link del link dev tap0
> close or another set_iff()
>
> So in this case, clean during close is not sufficient since it could be
> attached to another device.

In this case, close() still calls tun_detach() with clean=true, so
with my patch, the tx_array is still cleaned. What am I missing here?
Are you implying clean=true is not sufficient?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Patch net v2] tun: fix a memory leak for tfile->tx_array
  2018-01-13 17:31   ` Cong Wang
@ 2018-01-15  7:07     ` Jason Wang
  2018-01-15 19:36       ` Cong Wang
  0 siblings, 1 reply; 5+ messages in thread
From: Jason Wang @ 2018-01-15  7:07 UTC (permalink / raw)
  To: Cong Wang
  Cc: Linux Kernel Network Developers, Dmitry Vyukov, Michael S. Tsirkin



On 2018年01月14日 01:31, Cong Wang wrote:
> On Thu, Jan 11, 2018 at 2:16 AM, Jason Wang <jasowang@redhat.com> wrote:
>> It looks to me what is actual missed is the cleanups tun_detach_all(). For
>> me the only case that could leak is
>>
>> open
>> attach
>> ip link del link dev tap0
>> close or another set_iff()
>>
>> So in this case, clean during close is not sufficient since it could be
>> attached to another device.
> In this case, close() still calls tun_detach() with clean=true, so
> with my patch, the tx_array is still cleaned. What am I missing here?
> Are you implying clean=true is not sufficient?

Consider the corner case:

1) open
2) tun_set_iff() (which calls tun_attach to initialize skb_array)
3) ip link del link dev tap0 (which calls tun_detach_all())
4) tun_set_iff() (current codes does not forbid this and it will 
allocate skb array again)

Consider the skb array was only initialized when attach it to a real 
device, we should do the cleanup when we detach it from a device which 
happens on two places:

- actively: close to an tun fd (__tun_deatch())
- passively: tun device was destroyed (tun_detach_all())

Thanks

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Patch net v2] tun: fix a memory leak for tfile->tx_array
  2018-01-15  7:07     ` Jason Wang
@ 2018-01-15 19:36       ` Cong Wang
  0 siblings, 0 replies; 5+ messages in thread
From: Cong Wang @ 2018-01-15 19:36 UTC (permalink / raw)
  To: Jason Wang
  Cc: Linux Kernel Network Developers, Dmitry Vyukov, Michael S. Tsirkin

On Sun, Jan 14, 2018 at 11:07 PM, Jason Wang <jasowang@redhat.com> wrote:
>
>
> On 2018年01月14日 01:31, Cong Wang wrote:
>>
>> On Thu, Jan 11, 2018 at 2:16 AM, Jason Wang <jasowang@redhat.com> wrote:
>>>
>>> It looks to me what is actual missed is the cleanups tun_detach_all().
>>> For
>>> me the only case that could leak is
>>>
>>> open
>>> attach
>>> ip link del link dev tap0
>>> close or another set_iff()
>>>
>>> So in this case, clean during close is not sufficient since it could be
>>> attached to another device.
>>
>> In this case, close() still calls tun_detach() with clean=true, so
>> with my patch, the tx_array is still cleaned. What am I missing here?
>> Are you implying clean=true is not sufficient?
>
>
> Consider the corner case:
>
> 1) open
> 2) tun_set_iff() (which calls tun_attach to initialize skb_array)
> 3) ip link del link dev tap0 (which calls tun_detach_all())
> 4) tun_set_iff() (current codes does not forbid this and it will allocate
> skb array again)
>
> Consider the skb array was only initialized when attach it to a real device,
> we should do the cleanup when we detach it from a device which happens on
> two places:
>
> - actively: close to an tun fd (__tun_deatch())
> - passively: tun device was destroyed (tun_detach_all())

Fair enough, I will send out v3.

Thanks.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2018-01-15 19:37 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-10 18:51 [Patch net v2] tun: fix a memory leak for tfile->tx_array Cong Wang
2018-01-11 10:16 ` Jason Wang
2018-01-13 17:31   ` Cong Wang
2018-01-15  7:07     ` Jason Wang
2018-01-15 19:36       ` Cong Wang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).