Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1299663 > unrolled thread

net/netlink: memory leak in netlink_sendmsg

Started byDmitry Vyukov <dvyukov@google.com>
First post2015-12-31 13:00 +0100
Last post2016-01-11 21:30 +0100
Articles 4 — 4 participants

Back to article view | Back to linux.kernel


Contents

  net/netlink: memory leak in netlink_sendmsg Dmitry Vyukov <dvyukov@google.com> - 2015-12-31 13:00 +0100
    [PATCH] connector: bump skb->users before callback invocation Florian Westphal <fw@strlen.de> - 2015-12-31 14:30 +0100
      Re: [PATCH] connector: bump skb->users before callback invocation David Miller <davem@davemloft.net> - 2016-01-05 03:50 +0100
        Re: [PATCH] connector: bump skb->users before callback invocation Evgeniy Polyakov <zbr@ioremap.net> - 2016-01-11 21:30 +0100

#1299663 — net/netlink: memory leak in netlink_sendmsg

FromDmitry Vyukov <dvyukov@google.com>
Date2015-12-31 13:00 +0100
Subjectnet/netlink: memory leak in netlink_sendmsg
Message-ID<qLK3E-3Xl-1@gated-at.bofh.it>
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).
--
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/

[toc] | [next] | [standalone]


#1299667 — [PATCH] connector: bump skb->users before callback invocation

FromFlorian Westphal <fw@strlen.de>
Date2015-12-31 14:30 +0100
Subject[PATCH] connector: bump skb->users before callback invocation
Message-ID<qLLsJ-4VC-1@gated-at.bofh.it>
In reply to#1299663
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.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
 I wonder wth userspace can cram skb->len < NLMSG_HDRLEN
 down the kernel, it seems to beg for trouble...

diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
index d7373ca..25693b0 100644
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -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);
 	}
--
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/

[toc] | [prev] | [next] | [standalone]


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

FromDavid Miller <davem@davemloft.net>
Date2016-01-05 03:50 +0100
SubjectRe: [PATCH] connector: bump skb->users before callback invocation
Message-ID<qNpR8-3Te-9@gated-at.bofh.it>
In reply to#1299667
From: Florian Westphal <fw@strlen.de>
Date: Thu, 31 Dec 2015 14:26:33 +0100

> 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.
> 
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>

Applied and queued up for -stable, thanks.
--
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/

[toc] | [prev] | [next] | [standalone]


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

FromEvgeniy Polyakov <zbr@ioremap.net>
Date2016-01-11 21:30 +0100
SubjectRe: [PATCH] connector: bump skb->users before callback invocation
Message-ID<qPRgg-7mV-47@gated-at.bofh.it>
In reply to#1301241
Hi everyone

Thanks for fixing and quick pushing of this bug.

05.01.2016, 05:47, "David Miller" <davem@davemloft.net>:
> From: Florian Westphal <fw@strlen.de>
> Date: Thu, 31 Dec 2015 14:26:33 +0100
>
>>  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.
>>
>>  Reported-by: Dmitry Vyukov <dvyukov@google.com>
>>  Signed-off-by: Florian Westphal <fw@strlen.de>
>
> Applied and queued up for -stable, thanks.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web