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: <878tkrvp9r.fsf@xmission.com>
Date:   Fri, 16 Jun 2017 12:03:12 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Dick Streefland <dick@...eefland.net>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: autofs multi-map regression

Dick Streefland <dick@...eefland.net> writes:

> After a recent upgrade of a Ubuntu xenial machine, a particular
> autofs multi-map mount setup stopped working. A simplified example is:
>
> ::::::::::::::
> auto.master
> ::::::::::::::
> /net		/etc/auto.net
> ::::::::::::::
> auto.net
> ::::::::::::::
> localhost / :/ /loc :/loc
>
> Accessing /net/localhost/loc should trigger two nested bind mounts on
> /net/localhost and /net/localhost/loc, but with the new kernel, it fails
> with ELOOP:
>
> $ ls /net/localhost/loc
> ls: cannot open directory '/net/localhost/loc': Too many levels of symbolic links
>
> The problem is related to the upgrade of the Ubuntu xenial kernel from
> 4.4.0-38.57 to 4.4.0-78.99. I bisected the regression to commit
> 731ac92843877f3633325203abc942193c1e9001, which is a Ubuntu backport
> of this upstream kernel commit:
>
> commit 1064f874abc0d05eeed8993815f584d847b72486
> Author: Eric W. Biederman <ebiederm@...ssion.com>
> Date:   Fri Jan 20 18:28:35 2017 +1300
>
>     mnt: Tuck mounts under others instead of creating shadow/side mounts.

Interesting...

Can you test this on a stock 4.11 kernel?

I definitely need a little bit more information to solve this.  That
commit did not add any new error condidtions so I need to understand
what state you are getting yourself into that is affected by this
commit.

Is there a chance you can post /proc/self/mountinfo from when this is
happening?

Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ