netdev - Re: Memory leak in __ip6_rt_update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20230411161341.GA26208@u2004-local>
Date:   Tue, 11 Apr 2023 10:13:41 -0600
From:   David Ahern <dsahern@...nel.org>
To:     Matt Whitlock <kernel@...twhitlock.name>
Cc:     netdev@...r.kernel.org
Subject: Re: Memory leak in __ip6_rt_update_pmtu (net/ipv6/route.c)

On Sat, Apr 08, 2023 at 04:03:29PM -0400, Matt Whitlock wrote:
> Found while running 6.1.23-gentoo with kmemleak while trying to diagnose a
> probably unrelated memory leak:
> 
> unreferenced object 0xffff888042fc7b00 (size 256):
>  comm "softirq", pid 0, jiffies 4328682724 (age 5739.246s)
>  hex dump (first 32 bytes):
>    00 80 4d 01 81 88 ff ff 00 49 e3 94 ff ff ff ff  ..M......I......
>    60 ef 70 b5 81 88 ff ff a4 9c 0b 02 01 00 00 00  `.p.............
>  backtrace:
>    [<000000000b4f8d52>] dst_alloc+0x3c/0x140
>    [<0000000075b21562>] ip6_rt_cache_alloc.constprop.0+0x7b/0x190
>    [<00000000236d18fe>] __ip6_rt_update_pmtu+0x119/0x250
>    [<00000000e4b766f3>] inet6_csk_update_pmtu+0x42/0x80
>    [<00000000b86e1f12>] tcp_v6_mtu_reduced+0x35/0x80
>    [<00000000a854cc14>] tcp_v6_err+0x41f/0x480
>    [<00000000eff3ef2f>] icmpv6_notify+0xbb/0x180
>    [<00000000e4924371>] icmpv6_rcv+0x34a/0x3d0
>    [<000000007163d548>] ip6_protocol_deliver_rcu+0x75/0x3b0
>    [<00000000fdb6a323>] ip6_input_finish+0x35/0x60
>    [<00000000ebde6920>] ip6_sublist_rcv_finish+0x2d/0x40
>    [<00000000105dd24d>] ip6_sublist_rcv+0x191/0x210
>    [<00000000e87845f8>] ipv6_list_rcv+0xed/0x100
>    [<00000000206d66ad>] __netif_receive_skb_list_core+0x16c/0x1c0
>    [<0000000000117935>] netif_receive_skb_list_internal+0x173/0x270
>    [<00000000ea0594e7>] napi_complete_done+0x69/0x170
> unreferenced object 0xffff8881b570ef60 (size 96):
>  comm "softirq", pid 0, jiffies 4328682724 (age 5739.246s)
>  hex dump (first 32 bytes):
>    00 00 00 00 c8 05 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:
>    [<00000000adeef916>] kmalloc_trace+0x11/0x20
>    [<000000002752b81a>] dst_cow_metrics_generic+0x22/0x100
>    [<00000000b9c32bc3>] rt6_do_update_pmtu+0x34/0xb0
>    [<00000000c53e4e49>] __ip6_rt_update_pmtu+0x12c/0x250
>    [<00000000e4b766f3>] inet6_csk_update_pmtu+0x42/0x80
>    [<00000000b86e1f12>] tcp_v6_mtu_reduced+0x35/0x80
>    [<00000000a854cc14>] tcp_v6_err+0x41f/0x480
>    [<00000000eff3ef2f>] icmpv6_notify+0xbb/0x180
>    [<00000000e4924371>] icmpv6_rcv+0x34a/0x3d0
>    [<000000007163d548>] ip6_protocol_deliver_rcu+0x75/0x3b0
>    [<00000000fdb6a323>] ip6_input_finish+0x35/0x60
>    [<00000000ebde6920>] ip6_sublist_rcv_finish+0x2d/0x40
>    [<00000000105dd24d>] ip6_sublist_rcv+0x191/0x210
>    [<00000000e87845f8>] ipv6_list_rcv+0xed/0x100
>    [<00000000206d66ad>] __netif_receive_skb_list_core+0x16c/0x1c0
>    [<0000000000117935>] netif_receive_skb_list_internal+0x173/0x270
> 
> Note: The bottom object is referenced by the top object. (Look in the hex
> dump to see the address 0xffff8881b570ef60 in little-endian byte order at
> offset 16.)
> 
> To my unfamiliar eyes this would appear to be the most suspect bit of code
> (in __ip6_rt_update_pmtu at net/ipv6/route.c:2907):
> 
> 	nrt6 = ip6_rt_cache_alloc(&res, daddr, saddr);
> 	if (nrt6) {
> 		rt6_do_update_pmtu(nrt6, mtu);
> 		if (rt6_insert_exception(nrt6, &res))
> 			dst_release_immediate(&nrt6->dst);
> 	}
> 
> If rt6_insert_exception returns an error, we release the struct dst_entry
> (nrt6->dst), but what about the struct rt6_info (*nrt6) that we just
> allocated?

rt6_info is a container of dst_entry. As the stack trace above shows,
ip6_rt_cache_alloc -> dst_alloc. ie., freeing the dst_entry frees the
rt6_info.