netdev - Re: [PATCH net] sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0e434c61120b5b4a530731260c0f2c72ad02fa6f.camel@hammerspace.com>
Date: Sat, 26 Oct 2024 00:35:30 +0000
From: Trond Myklebust <trondmy@...merspace.com>
To: "liujian56@...wei.com" <liujian56@...wei.com>, "kuniyu@...zon.com"
	<kuniyu@...zon.com>
CC: "tom@...pey.com" <tom@...pey.com>, "davem@...emloft.net"
	<davem@...emloft.net>, "ebiederm@...ssion.com" <ebiederm@...ssion.com>,
	"chuck.lever@...cle.com" <chuck.lever@...cle.com>, "pabeni@...hat.com"
	<pabeni@...hat.com>, "okorniev@...hat.com" <okorniev@...hat.com>,
	"anna@...nel.org" <anna@...nel.org>, "kuba@...nel.org" <kuba@...nel.org>,
	"jlayton@...nel.org" <jlayton@...nel.org>, "Dai.Ngo@...cle.com"
	<Dai.Ngo@...cle.com>, "edumazet@...gle.com" <edumazet@...gle.com>,
	"neilb@...e.de" <neilb@...e.de>, "linux-nfs@...r.kernel.org"
	<linux-nfs@...r.kernel.org>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>
Subject: Re: [PATCH net] sunrpc: fix one UAF issue caused by sunrpc kernel tcp
 socket

On Fri, 2024-10-25 at 14:20 -0700, Kuniyuki Iwashima wrote:
> From: "liujian (CE)" <liujian56@...wei.com>
> Date: Fri, 25 Oct 2024 11:32:52 +0800
> > > > > If not, then what prevents it from happening?
> > > > The socket created by the userspace program obtains the
> > > > reference
> > > > counting of the namespace, but the kernel socket does not.
> > > > 
> > > > There's some discussion here:
> > > > https://lore.kernel.org/all/CANn89iJE5anTbyLJ0TdGAqGsE+GichY3YzQECjNUVMz=G3bcQg@mail.gmail.com/
> > > OK... So then it looks to me as if NFS, SMB, AFS, and any other
> > > networked filesystem that can be started from inside a container
> > > is
> > > going to need to do the same thing that rds appears to be doing.
> 
> FWIW, recently we saw a similar UAF on CIFS.
> 
> 
> > > 
> > > Should there perhaps be a helper function in the networking layer
> > > for
> > > this?
> > 
> > There should be no such helper function at present, right?.
> > 
> > If get net's reference to fix this problem, the following test is 
> > performed. There's nothing wrong with this case. I don't know if
> > there's 
> > anything else to consider.
> > 
> > I don't have any other ideas other than these two methods. Do you
> > have 
> > any suggestions on this problem? @Eric @Jakub ... @All
> 
> The netns lifetime should be managed by the upper layer rather than
> the networking layer.  If the netns is already dead, the upper layer
> must discard the net pointer anyway.
> 
> I suggest checking maybe_get_net() in NFS, CIFS, etc and then calling
> __sock_create() with kern 0.
> 

Thanks for the suggestion, but we already manage the netns lifetime in
the RPC layer. A reference is taken when the filesystem is being
mounted. It is dropped when the filesystem is being unmounted.

The problem is the TCP timer races on shutdown. There is no interest in
having to manage that in the RPC layer.



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