netdev - Re: [PATCH net-next] nfnetlink_queue: enable PID info retrieval

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: <1465572668.7945.62.camel@edumazet-glaptop3.roam.corp.google.com>
Date:	Fri, 10 Jun 2016 08:31:08 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	David Laight <David.Laight@...LAB.COM>
Cc:	Saeed Mahameed <saeedm@...lanox.com>,
	"David S. Miller" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>,
	Yevgeny Petrilin <yevgenyp@...lanox.com>,
	Andre Melkoumian <andre@...lanox.com>,
	Matthew Finlay <matt@...lanox.com>,
	Pablo Neira Ayuso <pablo@...filter.org>,
	Patrick McHardy <kaber@...sh.net>,
	Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>
Subject: Re: [PATCH net-next] nfnetlink_queue: enable PID info retrieval

On Fri, 2016-06-10 at 14:29 +0000, David Laight wrote:
> From: Eric Dumazet
> > Sent: 09 June 2016 22:17
> > On Thu, 2016-06-09 at 23:50 +0300, Saeed Mahameed wrote:
> > > From: Matthew Finlay <matt@...lanox.com>
> > 
> > 
> > > diff --git a/net/socket.c b/net/socket.c
> > > index a1bd161..67de200 100644
> > > --- a/net/socket.c
> > > +++ b/net/socket.c
> > > @@ -382,6 +382,7 @@ struct file *sock_alloc_file(struct socket *sock, int flags, const char *dname)
> > >  	}
> > >
> > >  	sock->file = file;
> > > +	file->f_owner.sock_pid  = find_get_pid(task_pid_nr(current));
> > >  	file->f_flags = O_RDWR | (flags & O_NONBLOCK);
> > >  	file->private_data = sock;
> > >  	return file;
> > 
> > Wow, that is a serious memory leak weapon (of struct pid)
> > 
> > Why don't you store the pid value, instead of a pointer ?
> 
> Since the numeric 'pid' values can be reused (with no grace time) you'd
> need to hold a reference to the pid structure (added in about 2.6.27) instead.
> Which is just a smaller memory leak!

Smaller than what ?


I fail to see how keeping a reference on the pid structure of the
process who created a socket can be useful, other than some optional
LSM.

A socket can be given via af_unix to another process.

Original process might have died.

Keeping a ref on the pid wont prevent this.

So the 'pid' here looks as a pure hint/info. Better store it directly
and avoid all the ref counting and indirection games that are going to
slow down nfnetlink quite a lot with all these extra cache line misses
and locks.