linux-kernel - Re: Mount structures are leaked

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: <20170608213707.GY6365@ZenIV.linux.org.uk>
Date:   Thu, 8 Jun 2017 22:37:07 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Andrei Vagin <avagin@...il.com>
Cc:     Kirill Tkhai <ktkhai@...tuozzo.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: Mount structures are leaked

On Thu, Jun 08, 2017 at 01:49:38PM -0700, Andrei Vagin wrote:
> Hello,
> 
> We found that mount structures are leaked on the upstream linux kernel:
> 
> [root@...m criu]# cat /proc/slabinfo | grep mnt
> mnt_cache          36456  36456    384   42    4 : tunables    0    0
>   0 : slabdata    868    868      0
> [root@...m criu]#  python test/zdtm.py run  -t zdtm/static/env00
> --iter 10 -f ns
> === Run 1/1 ================ zdtm/static/env00
> 
> ========================= Run zdtm/static/env00 in ns ==========================
> Start test
> ./env00 --pidfile=env00.pid --outfile=env00.out --envname=ENV_00_TEST
> Run criu dump
> Run criu restore
> Run criu dump
> ....
> Run criu restore
> Send the 15 signal to  339
> Wait for zdtm/static/env00(339) to die for 0.100000
> Removing dump/zdtm/static/env00/31
> ========================= Test zdtm/static/env00 PASS ==========================
> [root@...m criu]# cat /proc/slabinfo | grep mnt
> mnt_cache          36834  36834    384   42    4 : tunables    0    0
>   0 : slabdata    877    877      0
> 
> [root@...m linux]# git describe HEAD
> v4.12-rc4-122-gb29794e
> 
> [root@...m ~]# uname -a
> Linux zdtm.openvz.org 4.12.0-rc4+ #2 SMP Thu Jun 8 20:49:01 CEST 2017
> x86_64 x86_64 x86_64 GNU/Linux

For fsck sake...  Andrei, you *do* know better.
	1) I have no idea what setup do you have - e.g. whether you have mount event
propagation set up in a way that ends up with mounts accumulating somewhere.
	2) I have no idea what those scripts are and names don't look descriptive
enough to google for them in hope to find out (nor the version of those scripts,
if there had been more than one)
	3) I have no idea which config do you have.
	4) I have no idea which kernel is that about, other than "rc4 with something
on top of it"
	5) I have no idea how that had behaved on other kernels (or how that was
supposed to behave in the first place)

So it boils down to "we've done something, it has given a result we didn't expect,
the kernel must've been broken".  About the only thing I can suggest at that point is
telnet bofh.jeffballard.us 666
and see if it provides an inspiration...