[linux-yocto] [PATCH] netfilter: Fix kmemleak false positive reports

[He Zhe]

On 2018/10/25 18:29, Bruce Ashfield wrote:
> On 10/23/18 6:33 AM, zhe.he at windriver.com wrote:
>> From: He Zhe <zhe.he at windriver.com>
>>
>> unreferenced object 0xffff9643edb89900 (size 256):
>>    comm "sd-resolve", pid 220, jiffies 4295016710 (age 208.256s)
>>    hex dump (first 32 bytes):
>>      01 00 00 00 00 00 00 00 03 00 74 f3 ba b1 b6 b5  ..........t.....
>>      65 3e 00 00 00 00 00 00 90 f9 a0 ed 43 96 ff ff  e>..........C...
>>    backtrace:
>>      [<0000000070d5b185>] kmem_cache_alloc+0x146/0x200
>>      [<0000000007a27faa>] __nf_conntrack_alloc.isra.13+0x4d/0x170 [nf_conntrack]
>>      [<00000000ecc5b0ec>] init_conntrack+0x6a/0x2f0 [nf_conntrack]
>>      [<000000003d38809f>] nf_conntrack_in+0x2c5/0x360 [nf_conntrack]
>>      [<000000001fe154e3>] ipv4_conntrack_local+0x5d/0x70 [nf_conntrack_ipv4]
>>      [<0000000027adadb2>] nf_hook_slow+0x48/0xd0
>>      [<000000009893511f>] __ip_local_out+0xbd/0xf0
>>      [<00000000d68cbd2f>] ip_local_out+0x1c/0x50
>>      [<00000000995e2f37>] ip_send_skb+0x19/0x40
>>      [<000000003d95f220>] udp_send_skb.isra.5+0x157/0x360
>>      [<00000000ebc25968>] udp_sendmsg+0x9d8/0xc10
>>      [<000000003bef56ec>] inet_sendmsg+0x3e/0xf0
>>      [<000000008d23e405>] sock_sendmsg+0x1d/0x30
>>      [<000000008c297097>] ___sys_sendmsg+0x108/0x2b0
>>      [<00000000f15a806c>] __sys_sendmmsg+0xba/0x1c0
>>      [<00000000e195d2cf>] __x64_sys_sendmmsg+0x24/0x30
>>
>> In __nf_conntrack_confirm, object ct can be referenced to by the stack variable
>> ct and the members of ct->tuplehash. kmemleak needs at least one of them to find
>> the ct object during scan.
>>
>> When the ct object is moved from the unconfirmed hlist to the confirmed hlist.
>> kmemleak cannot see ct object if things happen in the following order and thus
>> give the above false positive report.
>> 1) ct object is removed from unconfirmed hlist.
>> 2) kmemleak scans data/bss sections.
>> 3) ct object is added to confirmed hlist and ct is destroyed as the function
>>     returns.
>> 4) kmemleak scans task stacks.
>>
>> This patch marks the ct object as not a leak.
>
> Has this also been submitted upstream ?
>
> Due to travel, I haven't gotten to it yet. But if it has been submitted
> upstream, I can get it merged by Monday

This has been submitted to lkml but has not got any attention. Mark
and I still are working on it to pinpoint the bad code.

Zhe

>
> Bruce
>
>>
>> Signed-off-by: He Zhe <zhe.he at windriver.com>
>> ---
>> This is only for v4.18
>>
>>   net/netfilter/nf_conntrack_core.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
>> index 3d52804..9b554c7 100644
>> --- a/net/netfilter/nf_conntrack_core.c
>> +++ b/net/netfilter/nf_conntrack_core.c
>> @@ -35,6 +35,7 @@
>>   #include <linux/mm.h>
>>   #include <linux/nsproxy.h>
>>   #include <linux/rculist_nulls.h>
>> +#include <linux/kmemleak.h>
>>     #include <net/netfilter/nf_conntrack.h>
>>   #include <net/netfilter/nf_conntrack_l3proto.h>
>> @@ -1138,6 +1139,8 @@ __nf_conntrack_alloc(struct net *net,
>>       if (ct == NULL)
>>           goto out;
>>   +    kmemleak_not_leak(ct);
>> +
>>       spin_lock_init(&ct->lock);
>>       ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple = *orig;
>>       ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.pprev = NULL;
>>
>
>