linux-kernel - Re: [kmemleak] unreferenced object 0xcd9c1a80 (size 192):

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

Message-ID: <20180212155556.5glgl6qorvuwvubs@ast-mbp.dhcp.thefacebook.com>
Date:   Mon, 12 Feb 2018 07:55:58 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     Yonghong Song <yhs@...com>, Mathieu Malaterre <malat@...ian.org>,
        Alexei Starovoitov <ast@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [kmemleak] unreferenced object 0xcd9c1a80 (size 192):

On Mon, Feb 12, 2018 at 09:28:33AM +0100, Daniel Borkmann wrote:
> On 02/12/2018 06:47 AM, Yonghong Song wrote:
> > On 2/11/18 11:18 AM, Mathieu Malaterre wrote:
> >> On Sun, Feb 11, 2018 at 5:54 PM, Alexei Starovoitov
> >> <alexei.starovoitov@...il.com> wrote:
> >>> On Sun, Feb 11, 2018 at 7:24 AM, Mathieu Malaterre <malat@...ian.org> wrote:
> >>>> Alexei,
> >>>>
> >>>> Could you please comment on why I am seeing those memleaks being
> >>>> reported on my ppc32 system ? Should they be marked as false positive
> >>>> ?
> >>>>
> >>>> System is Mac Mini G4, git/master (4.15.0+), ppc.
> >>>>
> >>>> Thanks for your time
> >>>>
> >>>> $ dmesg
> >>>> ...
> >>>> [ 1281.504173] kmemleak: 36 new suspected memory leaks (see
> >>>> /sys/kernel/debug/kmemleak)
> >>>>
> >>>> Where:
> >>>>
> >>>> # cat /sys/kernel/debug/kmemleak
> >>>> unreferenced object 0xdee25000 (size 192):
> >>>>    comm "systemd", pid 1, jiffies 4294894348 (age 1438.580s)
> >>>>    hex dump (first 32 bytes):
> >>>>      c0 56 2f 88 00 00 00 00 00 00 00 0b 00 00 00 0c  .V/.............
> >>>>      00 00 00 08 00 00 00 01 00 00 00 01 00 00 00 01  ................
> >>>>    backtrace:
> >>>>      [<6c69baf5>] trie_alloc+0xb0/0x150
> >>>>      [<fa093284>] SyS_bpf+0x288/0x1458
> >>>>      [<82182f53>] ret_from_syscall+0x0/0x38
> >>>> unreferenced object 0xdee25900 (size 192):
> >>>>    comm "systemd", pid 1, jiffies 4294894540 (age 1437.812s)
> >>>>    hex dump (first 32 bytes):
> >>>>      c0 56 2f 88 00 00 00 00 00 00 00 0b 00 00 00 08  .V/.............
> >>>>      00 00 00 08 00 00 00 01 00 00 00 01 00 00 00 01  ................
> >>>>    backtrace:
> >>>>      [<6c69baf5>] trie_alloc+0xb0/0x150
> >>>>      [<fa093284>] SyS_bpf+0x288/0x1458
> >>>>      [<82182f53>] ret_from_syscall+0x0/0x38
> >>>
> >>> hmm. looks real. Is there a reproducer?
> >>> Yonghong, lpm map not cleaning after itself?
> >>
> >> Not really. I simply boot up my machine and wait for the first kmemleak scan.
> > 
> > I am not able to reproduce the issue. Tried with latest net-next on FC26 with kmemleak on. I only got this one after bootup,
> > 'cat /sys/kernel/debug/kmemleak' or
> > 'echo scan > /sys/kernel/debug/kmemleak
> >  cat /sys/kernel/debug/kmemleak':
> > 
> > unreferenced object 0xffff99701a7386e0 (size 32):
> >   comm "mount", pid 1856, jiffies 4294669263 (age 98.440s)
> >   hex dump (first 32 bytes):
> >     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 00 00 00 00 00 00  ................
> >   backtrace:
> >     [<000000004668ec00>] security_sb_parse_opts_str+0x36/0x50
> >     [<00000000a9807d2b>] parse_security_options+0x3d/0x60
> >     [<00000000cc1e1d58>] btrfs_mount_root+0x139/0x720
> >     [<00000000bdc4f1a3>] mount_fs+0x30/0x150
> >     [<00000000f189f1bd>] vfs_kern_mount.part.26+0x54/0x100
> >     [<0000000093ae5db7>] btrfs_mount+0x184/0x914
> >     [<00000000bdc4f1a3>] mount_fs+0x30/0x150
> >     [<00000000f189f1bd>] vfs_kern_mount.part.26+0x54/0x100
> >     [<000000003b67b9fc>] do_mount+0x5b9/0xc70
> >     [<00000000de4073a0>] SyS_mount+0x80/0xd0
> >     [<00000000fc5a968a>] do_syscall_64+0x5d/0x110
> >     [<000000003d61f5fc>] entry_SYSCALL_64_after_hwframe+0x21/0x86
> >     [<00000000458a6ffa>] 0xffffffffffffffff
> > 
> > Not sure whether the above is a true issue or not.
> > 
> > However, by inspecting the code, I do find the trie_free in lpm_trie.c
> > may have missed freeing the trie memory.
> > 
> > The change likes below should work:
> > -bash-4.2$ git diff
> > diff --git a/kernel/bpf/lpm_trie.c b/kernel/bpf/lpm_trie.c
> > index 7b469d1..cecb259 100644
> > --- a/kernel/bpf/lpm_trie.c
> > +++ b/kernel/bpf/lpm_trie.c
> > @@ -589,6 +589,7 @@ static void trie_free(struct bpf_map *map)
> > 
> >  unlock:
> >         raw_spin_unlock(&trie->lock);
> > +       kfree(trie);

also looks like trie_free() is missing
synchronize_rcu() + rcu_barrier()
it doesn't wait for parallel lookup/update/delete to complete
before freeing the elements.