netdev - Re: [TEST] TCP MD5 vs kmemleak

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJwJo6ZjhLLSiBUntdGT8a6-d5pjdXyVv9AAQ3Yx1W01Nq=dwg@mail.gmail.com>
Date: Tue, 18 Jun 2024 04:24:08 +0100
From: Dmitry Safonov <0x7f454c46@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [TEST] TCP MD5 vs kmemleak

Hi Jakub,

thanks for pinging,

On Mon, 17 Jun 2024 at 15:24, Jakub Kicinski <kuba@...nel.org> wrote:
>
> Hi Dmitry!
>
> We added kmemleak checks to the selftest runners, TCP AO/MD5 tests seem
> to trip it:
>
> https://netdev-3.bots.linux.dev/vmksft-tcp-ao-dbg/results/643761/4-unsigned-md5-ipv6/stdout
>
> Could you take a look? kmemleak is not infallible, it could be a false
> positive.

Sure, that seems somewhat interesting, albeit at this moment not from
the TCP side :D

There is some pre-history to the related issue here:
https://lore.kernel.org/lkml/0000000000004d83170605e16003@google.com/

Which I was quite sure being addressed with what now is
https://git.kernel.org/linus/5f98fd034ca6

But now that I look at that commit, I see that kvfree_call_rcu() is
defined to __kvfree_call_rcu() under CONFIG_KASAN_GENERIC=n. And I
don't see the same kmemleak_ignore() on that path.

To double-check, you don't have kasan enabled on netdev runners, right?

And then straight away to another thought: the leak-report that you
get currently is ao_info, which should not happen if kfree_rcu() is
properly fixed.
But I'd expect kmemleak to be unhappy with ao keys freeing as well:
they are currently released with call_rcu(&key->rcu,
tcp_ao_key_free_rcu), which doesn't have a hint for kmemleak, too.

I'm going to take a look at it this week. Just to let you know, I'm
also looking at fixing those somewhat rare flakes on tcp-ao counters
checks (but that may be net-next material together with tracepoint
selftests).

Thanks,
             Dmitry