On 10/23/18 6:33 AM, zhe...@windriver.com wrote:
From: He Zhe <zhe...@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

Bruce


Signed-off-by: He Zhe <zhe...@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;


--
_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Reply via email to