netdev - Re: PROBLEM: Memory leak (at least with SLUB) from "secpath

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:	Mon, 22 Oct 2012 00:43:32 +0600
From:	Mike Kazantsev <mk.fraggod@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Paul Moore <paul@...l-moore.com>, netdev@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: PROBLEM: Memory leak (at least with SLUB) from "secpath_dup"
 (xfrm) in 3.5+ kernels

On Sun, 21 Oct 2012 19:57:01 +0600
Mike Kazantsev <mk.fraggod@...il.com> wrote:

> On Sun, 21 Oct 2012 15:29:43 +0200
> Eric Dumazet <eric.dumazet@...il.com> wrote:
> 
> > 
> > Did you try linux-3.7-rc2 (or linux-3.7-rc1) ?
> > 
> 
> I did not, will do in a few hours, thanks for the pointer.
> 

I just built "torvalds/linux-2.6" (v3.7-rc2) and rebooted into it,
started same rsync-over-net test and got kmalloc-64 leaking (it went up
to tens of MiB until I stopped rsync, normally these are fixed at ~500
KiB).

Unfortunately, I forgot to add slub_debug option and build kmemleak so
wasn't able to look at this case further, and when I rebooted with
these enabled/built, it was secpath_cache again.

So previously noted "slabtop showed 'kmalloc-64' being the 99% offender
in the past, but with recent kernels (3.6.1), it has changed to
'secpath_cache'" seem to be incorrect, as it seem to depend not on
kernel version, but some other factor.

Guess I'll try to reboot a few more times to see if I can catch
kmalloc-64 leaking (instead of secpath_cache) again.

-- 
Mike Kazantsev // fraggod.net

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)