linux-kernel - Re: tun: memory leak in tun_set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 17 Jan 2018 19:07:01 +0800
From:   Xin Long <lucien.xin@...il.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     David Miller <davem@...emloft.net>,
        Jason Wang <jasowang@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Willem de Bruijn <willemb@...gle.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller <syzkaller@...glegroups.com>
Subject: Re: tun: memory leak in tun_set_iff

On Wed, Jan 10, 2018 at 2:20 AM, Dmitry Vyukov <dvyukov@...gle.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.