* Memory leak in __ip6_rt_update_pmtu (net/ipv6/route.c)
@ 2023-04-08 20:03 Matt Whitlock
2023-04-11 16:13 ` David Ahern
0 siblings, 1 reply; 2+ messages in thread
From: Matt Whitlock @ 2023-04-08 20:03 UTC (permalink / raw)
To: netdev
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?
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Memory leak in __ip6_rt_update_pmtu (net/ipv6/route.c)
2023-04-08 20:03 Memory leak in __ip6_rt_update_pmtu (net/ipv6/route.c) Matt Whitlock
@ 2023-04-11 16:13 ` David Ahern
0 siblings, 0 replies; 2+ messages in thread
From: David Ahern @ 2023-04-11 16:13 UTC (permalink / raw)
To: Matt Whitlock; +Cc: netdev
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-04-11 16:15 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-04-08 20:03 Memory leak in __ip6_rt_update_pmtu (net/ipv6/route.c) Matt Whitlock
2023-04-11 16:13 ` David Ahern
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).