From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752855AbeAQLok (ORCPT + 1 other); Wed, 17 Jan 2018 06:44:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52402 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750908AbeAQLoj (ORCPT ); Wed, 17 Jan 2018 06:44:39 -0500 Subject: Re: tun: memory leak in tun_set_iff To: Xin Long , Dmitry Vyukov Cc: David Miller , Eric Dumazet , Willem de Bruijn , "Michael S. Tsirkin" , netdev , LKML , syzkaller References: From: Jason Wang Message-ID: <634f771a-dd75-12be-cd01-4356658ab9fa@redhat.com> Date: Wed, 17 Jan 2018 19:44:30 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 17 Jan 2018 11:44:39 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 2018年01月17日 19:07, Xin Long wrote: > On Wed, Jan 10, 2018 at 2:20 AM, Dmitry Vyukov 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