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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Tue, 18 Jun 2024 09:42:35 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Jakub Kicinski <kuba@...nel.org>, Dmitry Safonov <0x7f454c46@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	rcu@...r.kernel.org
Subject: Re: [TEST] TCP MD5 vs kmemleak

On Tue, Jun 18, 2024 at 06:30:59PM +0200, Paolo Abeni wrote:
> On Tue, 2024-06-18 at 07:40 -0700, Jakub Kicinski wrote:
> > On Tue, 18 Jun 2024 04:24:08 +0100 Dmitry Safonov wrote:
> > > 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?
> > 
> > We do:
> > 
> > CONFIG_KASAN=y
> > CONFIG_KASAN_GENERIC=y
> > 
> > here's the full config:
> > https://netdev-3.bots.linux.dev/vmksft-tcp-ao-dbg/results/645202/config
> > 
> > > 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).
> > 
> > Let me add rcu@ to CC, perhaps folks there can guide us on known false
> > positives with KASAN + kmemleak?
> 
> FTR, with mptcp self-tests we hit a few kmemleak false positive on RCU
> freed pointers, that where addressed by to this patch:
> 
> commit 5f98fd034ca6fd1ab8c91a3488968a0e9caaabf6
> Author: Catalin Marinas <catalin.marinas@....com>
> Date:   Sat Sep 30 17:46:56 2023 +0000
> 
>     rcu: kmemleak: Ignore kmemleak false positives when RCU-freeing objects
> 
> I'm wondering if this is hitting something similar? Possibly due to
> lazy RCU callbacks invoked after MSECS_MIN_AGE???

Fun!  ;-)

This commit handles memory passed to kfree_rcu() and friends, but
not memory passed to call_rcu() and friends.  Of course, call_rcu()
does not necessarily know the full extent of the memory passed to it,
for example, if passed a linked list, call_rcu() will know only about
the head of that list.

There are similar challenges with synchronize_rcu() and friends.

							Thanx, Paul