Skip to contentSkip to conversation

net/netlink: memory leak in netlink_sendmsg

PATCH In review Dmitry Vyukov 4 participants 4 messages Dec 31, 2015 – Jan 11, 2016

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

Hello,

The following program causes leak on 2 objects allocated in netlink_sendmsg:

https://gist.githubusercontent.com/dvyukov/e840d00cfefe66c5e064/raw/6e5343a936bd3edd1b0803941cf7c1427050d9a5/gistfile1.txt

unreferenced object 0xffff880014f54840 (size 224):
comm "a.out", pid 11468, jiffies 4301602943 (age 29.985s) 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 10 3b 9d 3d 00 88 ff ff  .........;.=....
  backtrace:
    [<     inline     >] kmemleak_alloc_recursive include/linux/kmemleak.h:47
    [<     inline     >] slab_post_alloc_hook mm/slub.c:1335
    [<     inline     >] slab_alloc_node mm/slub.c:2594
    [<ffffffff816cc44d>] kmem_cache_alloc_node+0x16d/0x2e0 mm/slub.c:2630
    [<ffffffff84b782ba>] __alloc_skb+0xba/0x5f0 net/core/skbuff.c:216
    [<     inline     >] alloc_skb include/linux/skbuff.h:814
    [<     inline     >] netlink_alloc_large_skb net/netlink/af_netlink.c:1695
    [<ffffffff84cfd4b4>] netlink_sendmsg+0xfd4/0x1760
net/netlink/af_netlink.c:2486
    [<     inline     >] sock_sendmsg_nosec net/socket.c:610
    [<ffffffff84b5cc5a>] sock_sendmsg+0xca/0x110 net/socket.c:620
    [<ffffffff84b5e689>] ___sys_sendmsg+0x309/0x840 net/socket.c:1946
    [<ffffffff84b60c94>] __sys_sendmmsg+0x134/0x330 net/socket.c:2031
    [<     inline     >] SYSC_sendmmsg net/socket.c:2059
    [<ffffffff84b60ec5>] SyS_sendmmsg+0x35/0x60 net/socket.c:2054
    [<ffffffff85c8eaf6>] entry_SYSCALL_64_fastpath+0x16/0x7a

arch/x86/entry/entry_64.S:185
unreferenced object 0xffff880014facf60 (size 512):
comm "a.out", pid 11468, jiffies 4301602943 (age 29.985s) hex dump (first 32 bytes):

    48 ea fa 14 00 88 ff ff 00 00 00 00 ad 4e ad de  H............N..
    ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff  ................
  backtrace:
    [<     inline     >] kmemleak_alloc_recursive include/linux/kmemleak.h:47
    [<     inline     >] slab_post_alloc_hook mm/slub.c:1335
    [<     inline     >] slab_alloc_node mm/slub.c:2594
    [<ffffffff816d0b77>] __kmalloc_node_track_caller+0x217/0x3e0 mm/slub.c:4096
    [<ffffffff84b75f71>] __kmalloc_reserve.isra.31+0x41/0xe0
net/core/skbuff.c:135
    [<ffffffff84b782f0>] __alloc_skb+0xf0/0x5f0 net/core/skbuff.c:228
    [<     inline     >] alloc_skb include/linux/skbuff.h:814
    [<     inline     >] netlink_alloc_large_skb net/netlink/af_netlink.c:1695
    [<ffffffff84cfd4b4>] netlink_sendmsg+0xfd4/0x1760
net/netlink/af_netlink.c:2486
    [<     inline     >] sock_sendmsg_nosec net/socket.c:610
    [<ffffffff84b5cc5a>] sock_sendmsg+0xca/0x110 net/socket.c:620
    [<ffffffff84b5e689>] ___sys_sendmsg+0x309/0x840 net/socket.c:1946
    [<ffffffff84b60c94>] __sys_sendmmsg+0x134/0x330 net/socket.c:2031
    [<     inline     >] SYSC_sendmmsg net/socket.c:2059
    [<ffffffff84b60ec5>] SyS_sendmmsg+0x35/0x60 net/socket.c:2054
    [<ffffffff85c8eaf6>] entry_SYSCALL_64_fastpath+0x16/0x7a

arch/x86/entry/entry_64.S:185

On commit 8513342170278468bac126640a5d2d12ffbff106 (Dec 28).

#1 lore raw

PATCH 1/1 connector: bump skb->users before callback invocation

Dmitry reports memleak with syskaller program.
Problem is that connector bumps skb usecount but might not invoke callback.

So move skb_get to where we invoke the callback.

---
I wonder wth userspace can cram skb->len < NLMSG_HDRLEN down the kernel, it seems to beg for trouble...

drivers/connector/connector.c +3 -8
index d7373ca..25693b0 100644
@@ -179,26 +179,21 @@ static int cn_call_callback(struct sk_buff *skb)
  *
  * It checks skb, netlink header and msg sizes, and calls callback helper.
  */
-static void cn_rx_skb(struct sk_buff *__skb)
+static void cn_rx_skb(struct sk_buff *skb)
 {
 	struct nlmsghdr *nlh;
-	struct sk_buff *skb;
 	int len, err;
 
-	skb = skb_get(__skb);
-
 	if (skb->len >= NLMSG_HDRLEN) {
 		nlh = nlmsg_hdr(skb);
 		len = nlmsg_len(nlh);
 
 		if (len < (int)sizeof(struct cn_msg) ||
 		    skb->len < nlh->nlmsg_len ||
-		    len > CONNECTOR_MAX_MSG_SIZE) {
-			kfree_skb(skb);
+		    len > CONNECTOR_MAX_MSG_SIZE)
 			return;
-		}
 
-		err = cn_call_callback(skb);
+		err = cn_call_callback(skb_get(skb));
 		if (err < 0)
 			kfree_skb(skb);
 	}
maintainer
#2 lore raw

Re: [PATCH] connector: bump skb->users before callback invocation

From: Florian Westphal <[email protected]>
Date: Thu, 31 Dec 2015 14:26:33 +0100

Quoted 7 lines

Dmitry reports memleak with syskaller program.
Problem is that connector bumps skb usecount but might not invoke callback.

So move skb_get to where we invoke the callback.

Applied and queued up for -stable, thanks.

#3 lore raw

Re: [PATCH] connector: bump skb->users before callback invocation

Hi everyone

Thanks for fixing and quick pushing of this bug.

05.01.2016, 05:47, "David Miller" <[email protected]>:

Quoted 12 lines

From: Florian Westphal <[email protected]>
Date: Thu, 31 Dec 2015 14:26:33 +0100

Quoted 7 lines

 Dmitry reports memleak with syskaller program.
 Problem is that connector bumps skb usecount but might not invoke callback.

 So move skb_get to where we invoke the callback.

Applied and queued up for -stable, thanks.