linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] igmp: address pmc kmemleak from on igmpv3_del_delrec()
@ 2017-02-03 21:20 Luis R. Rodriguez
  2017-02-07  0:32 ` Cong Wang
  0 siblings, 1 reply; 3+ messages in thread
From: Luis R. Rodriguez @ 2017-02-03 21:20 UTC (permalink / raw)
  To: davem, kuznet, jmorris, yoshfuji; +Cc: netdev, linux-kernel, Luis R. Rodriguez

When we igmpv3_add_delrec() we kzalloc the pmc, but when users
call    igmpv3_del_delrec() we never free the pmc. This was caught
by the following kmemleak splat:

unreferenced object 0xffff99666ff43b40 (size 192):
  comm "systemd-resolve", pid 1258, jiffies 4309905600 (age 2138.352s)
  hex dump (first 32 bytes):
    00 6a 64 72 66 99 ff ff e0 00 00 fc 00 00 00 00  .jdrf...........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffffb3a5f7ea>] kmemleak_alloc+0x4a/0xa0
    [<ffffffffb36044e7>] kmem_cache_alloc_trace+0x107/0x240
    [<ffffffffb39ddbed>] igmp_group_dropped+0xfd/0x270
    [<ffffffffb39de5cf>] ip_mc_dec_group+0xaf/0x110
    [<ffffffffb39de6e6>] ip_mc_leave_group+0xb6/0x140
    [<ffffffffb39a55d7>] do_ip_setsockopt.isra.13+0x4c7/0xed0
    [<ffffffffb39a6014>] ip_setsockopt+0x34/0xb0
    [<ffffffffb39ced9b>] udp_setsockopt+0x1b/0x30
    [<ffffffffb393f064>] sock_common_setsockopt+0x14/0x20
    [<ffffffffb393dd10>] SyS_setsockopt+0x80/0xe0
    [<ffffffffb3403b4b>] do_syscall_64+0x5b/0xc0
    [<ffffffffb3a6b3af>] return_from_SYSCALL_64+0x0/0x6a
    [<ffffffffffffffff>] 0xffffffffffffffff

Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---

I can reproduce this over time on a qemu box running next-20170125.
After running this for a while I no longer see the splat. This needs
confirmation form folks more familiar with the code, hence RFC. If
this is a real fix we need appropriate tags for the patch.

 net/ipv4/igmp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 5b15459955f8..44fd86de2823 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1172,6 +1172,7 @@ static void igmpv3_del_delrec(struct in_device *in_dev, struct ip_mc_list *im)
 				psf->sf_crcount = im->crcount;
 		}
 		in_dev_put(pmc->interface);
+		kfree(pmc);
 	}
 	spin_unlock_bh(&im->lock);
 }
-- 
2.11.0

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [RFC] igmp: address pmc kmemleak from on igmpv3_del_delrec()
  2017-02-03 21:20 [RFC] igmp: address pmc kmemleak from on igmpv3_del_delrec() Luis R. Rodriguez
@ 2017-02-07  0:32 ` Cong Wang
  2017-02-07  3:35   ` David Miller
  0 siblings, 1 reply; 3+ messages in thread
From: Cong Wang @ 2017-02-07  0:32 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: David Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
	Linux Kernel Network Developers, LKML, kernel, liuhangbin

On Fri, Feb 3, 2017 at 1:20 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> When we igmpv3_add_delrec() we kzalloc the pmc, but when users
> call    igmpv3_del_delrec() we never free the pmc. This was caught
> by the following kmemleak splat:
>
> unreferenced object 0xffff99666ff43b40 (size 192):
>   comm "systemd-resolve", pid 1258, jiffies 4309905600 (age 2138.352s)
>   hex dump (first 32 bytes):
>     00 6a 64 72 66 99 ff ff e0 00 00 fc 00 00 00 00  .jdrf...........
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<ffffffffb3a5f7ea>] kmemleak_alloc+0x4a/0xa0
>     [<ffffffffb36044e7>] kmem_cache_alloc_trace+0x107/0x240
>     [<ffffffffb39ddbed>] igmp_group_dropped+0xfd/0x270
>     [<ffffffffb39de5cf>] ip_mc_dec_group+0xaf/0x110
>     [<ffffffffb39de6e6>] ip_mc_leave_group+0xb6/0x140
>     [<ffffffffb39a55d7>] do_ip_setsockopt.isra.13+0x4c7/0xed0
>     [<ffffffffb39a6014>] ip_setsockopt+0x34/0xb0
>     [<ffffffffb39ced9b>] udp_setsockopt+0x1b/0x30
>     [<ffffffffb393f064>] sock_common_setsockopt+0x14/0x20
>     [<ffffffffb393dd10>] SyS_setsockopt+0x80/0xe0
>     [<ffffffffb3403b4b>] do_syscall_64+0x5b/0xc0
>     [<ffffffffb3a6b3af>] return_from_SYSCALL_64+0x0/0x6a
>     [<ffffffffffffffff>] 0xffffffffffffffff
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> ---
>
> I can reproduce this over time on a qemu box running next-20170125.
> After running this for a while I no longer see the splat. This needs
> confirmation form folks more familiar with the code, hence RFC. If
> this is a real fix we need appropriate tags for the patch.


Looks good to me. Adding some people who recent touched it to CC.

>
>  net/ipv4/igmp.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
> index 5b15459955f8..44fd86de2823 100644
> --- a/net/ipv4/igmp.c
> +++ b/net/ipv4/igmp.c
> @@ -1172,6 +1172,7 @@ static void igmpv3_del_delrec(struct in_device *in_dev, struct ip_mc_list *im)
>                                 psf->sf_crcount = im->crcount;
>                 }
>                 in_dev_put(pmc->interface);
> +               kfree(pmc);
>         }
>         spin_unlock_bh(&im->lock);
>  }
> --
> 2.11.0
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC] igmp: address pmc kmemleak from on igmpv3_del_delrec()
  2017-02-07  0:32 ` Cong Wang
@ 2017-02-07  3:35   ` David Miller
  0 siblings, 0 replies; 3+ messages in thread
From: David Miller @ 2017-02-07  3:35 UTC (permalink / raw)
  To: xiyou.wangcong
  Cc: mcgrof, kuznet, jmorris, yoshfuji, netdev, linux-kernel, kernel,
	liuhangbin

From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 6 Feb 2017 16:32:14 -0800

> On Fri, Feb 3, 2017 at 1:20 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
>> When we igmpv3_add_delrec() we kzalloc the pmc, but when users
>> call    igmpv3_del_delrec() we never free the pmc. This was caught
>> by the following kmemleak splat:
>>
>> unreferenced object 0xffff99666ff43b40 (size 192):
>>   comm "systemd-resolve", pid 1258, jiffies 4309905600 (age 2138.352s)
>>   hex dump (first 32 bytes):
>>     00 6a 64 72 66 99 ff ff e0 00 00 fc 00 00 00 00  .jdrf...........
>>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>>   backtrace:
>>     [<ffffffffb3a5f7ea>] kmemleak_alloc+0x4a/0xa0
>>     [<ffffffffb36044e7>] kmem_cache_alloc_trace+0x107/0x240
>>     [<ffffffffb39ddbed>] igmp_group_dropped+0xfd/0x270
>>     [<ffffffffb39de5cf>] ip_mc_dec_group+0xaf/0x110
>>     [<ffffffffb39de6e6>] ip_mc_leave_group+0xb6/0x140
>>     [<ffffffffb39a55d7>] do_ip_setsockopt.isra.13+0x4c7/0xed0
>>     [<ffffffffb39a6014>] ip_setsockopt+0x34/0xb0
>>     [<ffffffffb39ced9b>] udp_setsockopt+0x1b/0x30
>>     [<ffffffffb393f064>] sock_common_setsockopt+0x14/0x20
>>     [<ffffffffb393dd10>] SyS_setsockopt+0x80/0xe0
>>     [<ffffffffb3403b4b>] do_syscall_64+0x5b/0xc0
>>     [<ffffffffb3a6b3af>] return_from_SYSCALL_64+0x0/0x6a
>>     [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
>> ---
>>
>> I can reproduce this over time on a qemu box running next-20170125.
>> After running this for a while I no longer see the splat. This needs
>> confirmation form folks more familiar with the code, hence RFC. If
>> this is a real fix we need appropriate tags for the patch.
> 
> 
> Looks good to me. Adding some people who recent touched it to CC.

The kfree() was removed in commit:

====================
commit 24803f38a5c0b6c57ed800b47e695f9ce474bc3a
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Mon Nov 14 16:16:28 2016 +0800

    igmp: do not remove igmp souce list info when set link down
====================

But I don't see what could possibly continue to reference this
pmc after we unlink it from the list.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-02-07  3:35 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-03 21:20 [RFC] igmp: address pmc kmemleak from on igmpv3_del_delrec() Luis R. Rodriguez
2017-02-07  0:32 ` Cong Wang
2017-02-07  3:35   ` David Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).