linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* tun: memory leak in tun_set_iff
@ 2018-01-09 18:20 Dmitry Vyukov
  2018-01-17 11:07 ` Xin Long
  0 siblings, 1 reply; 3+ messages in thread
From: Dmitry Vyukov @ 2018-01-09 18:20 UTC (permalink / raw)
  To: David Miller, Jason Wang, Eric Dumazet, Willem de Bruijn,
	Michael S. Tsirkin, netdev, LKML, syzkaller

[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]

Hello,

syzkaller has hit the following memory leak on 4.15-rc7.
Reproducer is attached.

unreeferenced object 0xffff88002c9ac400 (size 4096):
  comm "syz-executor0", pid 12349, jiffies 4295751114 (age 10.067s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<00000000ad172f4e>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
    [<00000000ad172f4e>] slab_post_alloc_hook mm/slab.h:440 [inline]
    [<00000000ad172f4e>] slab_alloc_node mm/slub.c:2725 [inline]
    [<00000000ad172f4e>] slab_alloc mm/slub.c:2733 [inline]
    [<00000000ad172f4e>] __kmalloc+0x1a9/0x340 mm/slub.c:3758
    [<00000000d66b86d6>] kmalloc_array include/linux/slab.h:618 [inline]
    [<00000000d66b86d6>] kcalloc include/linux/slab.h:629 [inline]
    [<00000000d66b86d6>] __ptr_ring_init_queue_alloc
include/linux/ptr_ring.h:450 [inline]
    [<00000000d66b86d6>] ptr_ring_init include/linux/ptr_ring.h:468 [inline]
    [<00000000d66b86d6>] skb_array_init include/linux/skb_array.h:176 [inline]
    [<00000000d66b86d6>] tun_attach+0x940/0x10b0 drivers/net/tun.c:754
    [<000000007a69e5cb>] tun_set_iff drivers/net/tun.c:2315 [inline]
    [<000000007a69e5cb>] __tun_chr_ioctl+0x2435/0x4210 drivers/net/tun.c:2524
    [<000000005c75f6a6>] tun_chr_ioctl+0x2a/0x40 drivers/net/tun.c:2773
    [<00000000ece2f188>] vfs_ioctl fs/ioctl.c:46 [inline]
    [<00000000ece2f188>] file_ioctl fs/ioctl.c:500 [inline]
    [<00000000ece2f188>] do_vfs_ioctl+0x1cf/0x16b0 fs/ioctl.c:684
    [<0000000021f4fda7>] SYSC_ioctl fs/ioctl.c:701 [inline]
    [<0000000021f4fda7>] SyS_ioctl+0xb6/0xe0 fs/ioctl.c:692
    [<0000000001148918>] entry_SYSCALL_64_fastpath+0x23/0x9a
    [<000000008d0cf26e>] 0xffffffffffffffff

[-- Attachment #2: tun.c --]
[-- Type: text/x-csrc, Size: 942 bytes --]

// autogenerated by syzkaller (http://github.com/google/syzkaller)
#define _GNU_SOURCE
#include <endian.h>
#include <fcntl.h>
#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <unistd.h>

int main()
{
  syscall(__NR_mmap, 0x20000000, 0xfff000, 3, 0x32, -1, 0);
  int fd = syscall(__NR_open, "/dev/net/tun", 0);
  *(uint32_t*)0x2021b000 = 9;
  syscall(__NR_ioctl, fd, 0x400454da, 0x2021b000);
  memcpy((void*)0x20533000,
    "\x02\x00\x00\x00\x04\x00\x00\x00\x00\x04\x00\x80\x00\xe9\xbc\x22", 16);
  *(uint32_t*)0x20533010 = 0x10001;
  *(uint32_t*)0x20533014 = 0;
  *(uint64_t*)0x20533018 = 0x20012fe8;
  *(uint32_t*)0x20012fe8 = 0;
  *(uint32_t*)0x20012fec = 0;
  *(uint32_t*)0x20012ff0 = 0;
  *(uint32_t*)0x20012ff4 = 0;
  *(uint32_t*)0x20012ff8 = 0;
  *(uint16_t*)0x20012ffc = 0;
  *(uint16_t*)0x20012ffe = 0;
  syscall(__NR_ioctl, fd, 0x400454ca, 0x20533000);
  return 0;
}

^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: tun: memory leak in tun_set_iff
  2018-01-09 18:20 tun: memory leak in tun_set_iff Dmitry Vyukov
@ 2018-01-17 11:07 ` Xin Long
  2018-01-17 11:44   ` Jason Wang
  0 siblings, 1 reply; 3+ messages in thread
From: Xin Long @ 2018-01-17 11:07 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: David Miller, Jason Wang, Eric Dumazet, Willem de Bruijn,
	Michael S. Tsirkin, netdev, LKML, syzkaller

On Wed, Jan 10, 2018 at 2:20 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> Hello,
>
> syzkaller has hit the following memory leak on 4.15-rc7.
> Reproducer is attached.
>
> unreeferenced object 0xffff88002c9ac400 (size 4096):
>   comm "syz-executor0", pid 12349, jiffies 4295751114 (age 10.067s)
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<00000000ad172f4e>] kmemleak_alloc_recursive
> include/linux/kmemleak.h:55 [inline]
>     [<00000000ad172f4e>] slab_post_alloc_hook mm/slab.h:440 [inline]
>     [<00000000ad172f4e>] slab_alloc_node mm/slub.c:2725 [inline]
>     [<00000000ad172f4e>] slab_alloc mm/slub.c:2733 [inline]
>     [<00000000ad172f4e>] __kmalloc+0x1a9/0x340 mm/slub.c:3758
>     [<00000000d66b86d6>] kmalloc_array include/linux/slab.h:618 [inline]
>     [<00000000d66b86d6>] kcalloc include/linux/slab.h:629 [inline]
>     [<00000000d66b86d6>] __ptr_ring_init_queue_alloc
> include/linux/ptr_ring.h:450 [inline]
>     [<00000000d66b86d6>] ptr_ring_init include/linux/ptr_ring.h:468 [inline]
>     [<00000000d66b86d6>] skb_array_init include/linux/skb_array.h:176 [inline]
>     [<00000000d66b86d6>] tun_attach+0x940/0x10b0 drivers/net/tun.c:754
>     [<000000007a69e5cb>] tun_set_iff drivers/net/tun.c:2315 [inline]
>     [<000000007a69e5cb>] __tun_chr_ioctl+0x2435/0x4210 drivers/net/tun.c:2524
>     [<000000005c75f6a6>] tun_chr_ioctl+0x2a/0x40 drivers/net/tun.c:2773
>     [<00000000ece2f188>] vfs_ioctl fs/ioctl.c:46 [inline]
>     [<00000000ece2f188>] file_ioctl fs/ioctl.c:500 [inline]
>     [<00000000ece2f188>] do_vfs_ioctl+0x1cf/0x16b0 fs/ioctl.c:684
>     [<0000000021f4fda7>] SYSC_ioctl fs/ioctl.c:701 [inline]
>     [<0000000021f4fda7>] SyS_ioctl+0xb6/0xe0 fs/ioctl.c:692
>     [<0000000001148918>] entry_SYSCALL_64_fastpath+0x23/0x9a
>     [<000000008d0cf26e>] 0xffffffffffffffff
we probably just need:
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -831,8 +831,10 @@ static int tun_attach(struct tun_struct *tun,
struct file *file,
                /* Setup XDP RX-queue info, for new tfile getting attached */
                err = xdp_rxq_info_reg(&tfile->xdp_rxq,
                                       tun->dev, tfile->queue_index);
-               if (err < 0)
+               if (err < 0) {
+                       ptr_ring_cleanup(&tfile->tx_ring, NULL);
                        goto out;
+               }

will check it for sure.

^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: tun: memory leak in tun_set_iff
  2018-01-17 11:07 ` Xin Long
@ 2018-01-17 11:44   ` Jason Wang
  0 siblings, 0 replies; 3+ messages in thread
From: Jason Wang @ 2018-01-17 11:44 UTC (permalink / raw)
  To: Xin Long, Dmitry Vyukov
  Cc: David Miller, Eric Dumazet, Willem de Bruijn, Michael S. Tsirkin,
	netdev, LKML, syzkaller



On 2018年01月17日 19:07, Xin Long wrote:
> On Wed, Jan 10, 2018 at 2:20 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>> Hello,
>>
>> syzkaller has hit the following memory leak on 4.15-rc7.
>> Reproducer is attached.
>>
>> unreeferenced object 0xffff88002c9ac400 (size 4096):
>>    comm "syz-executor0", pid 12349, jiffies 4295751114 (age 10.067s)
>>    hex dump (first 32 bytes):
>>      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>>      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>>    backtrace:
>>      [<00000000ad172f4e>] kmemleak_alloc_recursive
>> include/linux/kmemleak.h:55 [inline]
>>      [<00000000ad172f4e>] slab_post_alloc_hook mm/slab.h:440 [inline]
>>      [<00000000ad172f4e>] slab_alloc_node mm/slub.c:2725 [inline]
>>      [<00000000ad172f4e>] slab_alloc mm/slub.c:2733 [inline]
>>      [<00000000ad172f4e>] __kmalloc+0x1a9/0x340 mm/slub.c:3758
>>      [<00000000d66b86d6>] kmalloc_array include/linux/slab.h:618 [inline]
>>      [<00000000d66b86d6>] kcalloc include/linux/slab.h:629 [inline]
>>      [<00000000d66b86d6>] __ptr_ring_init_queue_alloc
>> include/linux/ptr_ring.h:450 [inline]
>>      [<00000000d66b86d6>] ptr_ring_init include/linux/ptr_ring.h:468 [inline]
>>      [<00000000d66b86d6>] skb_array_init include/linux/skb_array.h:176 [inline]
>>      [<00000000d66b86d6>] tun_attach+0x940/0x10b0 drivers/net/tun.c:754
>>      [<000000007a69e5cb>] tun_set_iff drivers/net/tun.c:2315 [inline]
>>      [<000000007a69e5cb>] __tun_chr_ioctl+0x2435/0x4210 drivers/net/tun.c:2524
>>      [<000000005c75f6a6>] tun_chr_ioctl+0x2a/0x40 drivers/net/tun.c:2773
>>      [<00000000ece2f188>] vfs_ioctl fs/ioctl.c:46 [inline]
>>      [<00000000ece2f188>] file_ioctl fs/ioctl.c:500 [inline]
>>      [<00000000ece2f188>] do_vfs_ioctl+0x1cf/0x16b0 fs/ioctl.c:684
>>      [<0000000021f4fda7>] SYSC_ioctl fs/ioctl.c:701 [inline]
>>      [<0000000021f4fda7>] SyS_ioctl+0xb6/0xe0 fs/ioctl.c:692
>>      [<0000000001148918>] entry_SYSCALL_64_fastpath+0x23/0x9a
>>      [<000000008d0cf26e>] 0xffffffffffffffff
> we probably just need:
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -831,8 +831,10 @@ static int tun_attach(struct tun_struct *tun,
> struct file *file,
>                  /* Setup XDP RX-queue info, for new tfile getting attached */
>                  err = xdp_rxq_info_reg(&tfile->xdp_rxq,
>                                         tun->dev, tfile->queue_index);
> -               if (err < 0)
> +               if (err < 0) {
> +                       ptr_ring_cleanup(&tfile->tx_ring, NULL);
>                          goto out;
> +               }
>
> will check it for sure.

Good catch. This looks like a new bug in net-next instead of the what 
memory leaker told us here.

Wang Cong has posted a possible fix for this.

Thanks

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-01-17 11:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-09 18:20 tun: memory leak in tun_set_iff Dmitry Vyukov
2018-01-17 11:07 ` Xin Long
2018-01-17 11:44   ` Jason 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).