Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756153AbbLAM1p (ORCPT <rfc822;w@1wt.eu>);
	Tue, 1 Dec 2015 07:27:45 -0500
Received: from mail-wm0-f54.google.com ([74.125.82.54]:35438 "EHLO
	mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1755029AbbLAM1n (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 1 Dec 2015 07:27:43 -0500
MIME-Version: 1.0
From: Dmitry Vyukov <dvyukov@google.com>
Date: Tue, 1 Dec 2015 13:27:22 +0100
Message-ID: <CACT4Y+bv56b+opCd=5SHmN47MAHEFyZA18kSsu-Fa+XODj20PA@mail.gmail.com>
Subject: memory leak in do_ipv6_setsockopt
To: "David S. Miller" <davem@davemloft.net>,
        Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
        James Morris <jmorris@namei.org>,
        Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
        Patrick McHardy <kaber@trash.net>, netdev <netdev@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Vlad Yasevich <vyasevich@gmail.com>,
        Neil Horman <nhorman@tuxdriver.com>, linux-sctp@vger.kernel.org
Cc: syzkaller <syzkaller@googlegroups.com>, Kostya Serebryany <kcc@google.com>,
        Alexander Potapenko <glider@google.com>,
        Sasha Levin <sasha.levin@oracle.com>,
        Eric Dumazet <edumazet@google.com>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1919
Lines: 50

Hello,

The following program causes a memory leak :

// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include <syscall.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <string.h>
#include <stdint.h>
#include <linux/in.h>
#include <linux/socket.h>

int main()
{
        long r1 = syscall(SYS_socket, PF_INET6,
SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_SCTP);
        const char *opt = "\x15\x53\x5e\x2d\x97\xab\xe1";
        long r3 = syscall(SYS_setsockopt, r1, 0x29ul, 0x6ul, opt, 0x7ul);
        return 0;
}


unreferenced object 0xffff880039a55260 (size 64):
  comm "executor", pid 11746, jiffies 4298984475 (age 16.078s)
  hex dump (first 32 bytes):
    2f 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:
    [<     inline     >] kmalloc include/linux/slab.h:463
    [<ffffffff848a2f5f>] sock_kmalloc+0x7f/0xc0 net/core/sock.c:1774
    [<ffffffff84e5bea0>] do_ipv6_setsockopt.isra.7+0x15d0/0x2830
net/ipv6/ipv6_sockglue.c:483
    [<ffffffff84e5d19b>] ipv6_setsockopt+0x9b/0x140 net/ipv6/ipv6_sockglue.c:885
    [<ffffffff8544616c>] sctp_setsockopt+0x15c/0x36c0 net/sctp/socket.c:3702
    [<ffffffff848a2035>] sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2645
    [<     inline     >] SYSC_setsockopt net/socket.c:1757
    [<ffffffff8489f1d8>] SyS_setsockopt+0x158/0x240 net/socket.c:1736


I confirmed that running this program in a loop steadily increases
number of objects in kmalloc-64 slab. The leak does not happen with
IPPROTO_TCP, so probably it is sctp-related.

On commit 31ade3b83e1821da5fbb2f11b5b3d4ab2ec39db8 (Nov 29).
--
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/