linux-kernel - Re: [PATCH net 2/2] auth_gss: Fix deadlock that blocks rpcsec_gss_exit

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: <a845b544c6592e58feeaff3be9271a717f53b383.camel@hammerspace.com>
Date:   Tue, 28 Sep 2021 13:30:17 +0000
From:   Trond Myklebust <trondmy@...merspace.com>
To:     "neilb@...e.com" <neilb@...e.com>,
        "timo@...henpieler.org" <timo@...henpieler.org>,
        "bfields@...ldses.org" <bfields@...ldses.org>,
        "tyhicks@...onical.com" <tyhicks@...onical.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "wanghai38@...wei.com" <wanghai38@...wei.com>,
        "nicolas.dichtel@...nd.com" <nicolas.dichtel@...nd.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "jlayton@...nel.org" <jlayton@...nel.org>,
        "dsahern@...il.com" <dsahern@...il.com>,
        "christian.brauner@...ntu.com" <christian.brauner@...ntu.com>,
        "jiang.wang@...edance.com" <jiang.wang@...edance.com>,
        "anna.schumaker@...app.com" <anna.schumaker@...app.com>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "cong.wang@...edance.com" <cong.wang@...edance.com>,
        "ast@...nel.org" <ast@...nel.org>,
        "kuniyu@...zon.co.jp" <kuniyu@...zon.co.jp>,
        "willy@...radead.org" <willy@...radead.org>,
        "wenbin.zeng@...il.com" <wenbin.zeng@...il.com>,
        "tom@...pey.com" <tom@...pey.com>,
        "chuck.lever@...cle.com" <chuck.lever@...cle.com>,
        "Rao.Shoaib@...cle.com" <Rao.Shoaib@...cle.com>,
        "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>,
        "kolga@...app.com" <kolga@...app.com>
CC:     "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net 2/2] auth_gss: Fix deadlock that blocks
 rpcsec_gss_exit_net when use-gss-proxy==1

On Tue, 2021-09-28 at 11:14 +0800, Wang Hai wrote:
> When use-gss-proxy is set to 1, write_gssp() creates a rpc client in
> gssp_rpc_create(), this increases the netns refcount by 2, these
> refcounts are supposed to be released in rpcsec_gss_exit_net(), but
> it
> will never happen because rpcsec_gss_exit_net() is triggered only
> when
> the netns refcount gets to 0, specifically:
>     refcount=0 -> cleanup_net() -> ops_exit_list ->
> rpcsec_gss_exit_net
> It is a deadlock situation here, refcount will never get to 0 unless
> rpcsec_gss_exit_net() is called. So, in this case, the netns refcount
> should not be increased.
> 
> In this case, xprt will take a netns refcount which is not supposed
> to be taken. Add a new flag to rpc_create_args called
> RPC_CLNT_CREATE_NO_NET_REF for not increasing the netns refcount.
> 
> It is safe not to hold the netns refcount, because when
> cleanup_net(), it
> will hold the gssp_lock and then shut down the rpc client
> synchronously.
> 
> 
I don't like this solution at all. Adding this kind of flag is going to
lead to problems down the road.

Is there any reason whatsoever why we need this RPC client to exist
when there is no active knfsd server? IOW: Is there any reason why we
shouldn't defer creating this RPC client for when knfsd starts up in
this net namespace, and why we can't shut it down when knfsd shuts
down?

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@...merspace.com