net/netlink: memory leak in netlink_sendmsg

274 views
Skip to first unread message

Dmitry Vyukov

unread,
Dec 31, 2015, 6:51:39 AM12/31/15
to David S. Miller, Herbert Xu, Thomas Graf, Daniel Borkmann, Ken-ichirou MATSUZAWA, Nicolas Dichtel, Florian Westphal, netdev, LKML, syzkaller, Kostya Serebryany, Alexander Potapenko, Sasha Levin, Eric Dumazet
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).

Florian Westphal

unread,
Dec 31, 2015, 8:26:47 AM12/31/15
to Dmitry Vyukov, David S. Miller, Herbert Xu, Thomas Graf, Daniel Borkmann, Ken-ichirou MATSUZAWA, Nicolas Dichtel, Florian Westphal, netdev, LKML, syzkaller, Kostya Serebryany, Alexander Potapenko, Sasha Levin, Eric Dumazet, z...@ioremap.net
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 <dvy...@google.com>
Signed-off-by: Florian Westphal <f...@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);
}

David Miller

unread,
Jan 4, 2016, 9:47:39 PM1/4/16
to f...@strlen.de, dvy...@google.com, her...@gondor.apana.org.au, tg...@suug.ch, dan...@iogearbox.net, cham...@gmail.com, nicolas...@6wind.com, net...@vger.kernel.org, linux-...@vger.kernel.org, syzk...@googlegroups.com, k...@google.com, gli...@google.com, sasha...@oracle.com, edum...@google.com, z...@ioremap.net
From: Florian Westphal <f...@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 <dvy...@google.com>
> Signed-off-by: Florian Westphal <f...@strlen.de>

Applied and queued up for -stable, thanks.
Reply all
Reply to author
Forward
0 new messages