netdev - [4.18-stable 1/1] netfilter: use kvmalloc_array to allocate memory for hashtable

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>] [day] [month] [year] [list]

Message-ID: <12867703.EeJsGSpq3u@yow-masselst-lx1>
Date:   Thu, 25 Oct 2018 16:18:51 -0400
From:   Mark Asselstine <mark.asselstine@...driver.com>
To:     <netdev@...r.kernel.org>, David Miller <davem@...emloft.net>
Subject: [4.18-stable 1/1] netfilter: use kvmalloc_array to allocate memory for hashtable

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