Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 13 Sep 2022 18:48:05 +0100
From:   Al Viro <viro@zeniv.linux.org.uk>
To:     Jann Horn <jannh@google.com>
Cc:     linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        David Howells <dhowells@redhat.com>,
        kernel list <linux-kernel@vger.kernel.org>
Subject: Re: BUG: d_path() races with do_move_mount() on ->mnt_ns, leading to
 use-after-free
Message-ID: <YyDCVSaA2Kjnz/a5@ZenIV>
References: <CAG48ez2dS04ONb-EVQGOtmeU6vTpKLe4J0W1yqa+Q9j+Hg3hFw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAG48ez2dS04ONb-EVQGOtmeU6vTpKLe4J0W1yqa+Q9j+Hg3hFw@mail.gmail.com>
Sender: Al Viro <viro@ftp.linux.org.uk>
Precedence: bulk

On Tue, Sep 13, 2022 at 07:14:56PM +0200, Jann Horn wrote:
> As the subject says, there's a race between d_path() (specifically
> __prepend_path()) looking at mnt->mnt_ns with is_anon_ns(), and
> do_move_mount() switching out the ->mnt_ns and freeing the old one.
> This can theoretically lead to a use-after-free read, but it doesn't
> seem to be very interesting from a security perspective, since all it
> gets you is a comparison of a value in freed memory with zero.

... with d_absolute_path() being the only caller that might even
theoretically care.

	Anyway, shouldn't be hard to deal with - adding rcu_head to
struct mnt_namespace (anon-unioned with e.g. ->list) and turning kfree()
in free_mnt_ns() into kfree_rcu() ought to do it...