David,
Please promote mainline commit 285189c78eeb6f684a024b86fb5997d10c6aa564
[netfilter: use kvmalloc_array to allocate memory for hashtable] to
linux-4.18.y stable. As it happens this not only fixes the issue described in
the commit log, it also solves the issue of kmemleak reporting false positives
of 'struct nf_conn' objects.
unreferenced object 0xffff9af78fa6de00 (size 256):
comm "rdate", pid 4215, jiffies 4299506036 (age 115.149s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 0a 00 96 98 f7 9a ff ff ................
45 e6 00 00 00 00 00 00 10 99 a3 94 f7 9a ff ff E...............
backtrace:
[<0000000006b47d03>] kmem_cache_alloc+0x146/0x200
[<00000000dbb53245>] __nf_conntrack_alloc.isra.13+0x4d/0x170[nf_conntrack]
[<000000008c1c1285>] init_conntrack+0x6a/0x2f0 [nf_conntrack]
[<00000000a6dd3a04>] nf_conntrack_in+0x2c5/0x360 [nf_conntrack]
[<0000000000213d80>] ipv4_conntrack_local+0x5d/0x70 [nf_conntrack_ipv4]
[<00000000d98fc633>] nf_hook_slow+0x48/0xd0
[<00000000fea9b61e>] __ip_local_out+0xbd/0xf0
[<00000000e1418ed2>] ip_local_out+0x1c/0x50
[<0000000071f63135>] ip_queue_xmit+0x15f/0x3d0
[<000000008fb87cfd>] __tcp_transmit_skb+0x5bf/0xab0
[<0000000073c7808d>] tcp_connect+0x648/0x830
[<000000000e12e101>] tcp_v4_connect+0x458/0x4d0
[<000000003223764c>] __inet_stream_connect+0xe2/0x380
[<000000005c32d180>] inet_stream_connect+0x3b/0x60
[<00000000465bcd15>] __sys_connect+0xce/0x100
[<0000000055a63178>] __x64_sys_connect+0x1a/0x20
The main object pointer to these struct nf_conn objects is 'salted' with
ip_conntrack_info in sk_buff._nfct, and as such is not a viable pointer to
this object by the kmemleak logic.
The only other consistent reference to these objects or contents is found in
the hash table. But it appears that kmemleak does not scan the
nf_conntrack_hash which is initialized in nf_ct_alloc_hashtable() via
__get_free_pages(). This results in the objects appearing as "leaks".
I could solve this by keeping the original code and adding a call to
kmemleak_alloc() in nf_ct_alloc_hashtable() and similarly a call to
kmemleak_free() in nf_ct_free_hashtable(). But since this mainline commit
exists which happens to also sort out this issue we are most likely best to do
the backport and kill two birds with one stone.
He Zhe previously sent out a patch to this list "[RFC] [PATCH] netfilter: Fix
kmemleak false positive reports". With the additional analysis summarized here
that patch should not be considered for merging.
Thanks,
Mark Asselstine
