netdev - Re: [PATCH net-next v2 2/2] tcp_diag: report TCP MD5 signing keys and addresses

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: <20170826055348.jjzv3n5vao34mkgb@ycc.fr>
Date:   Sat, 26 Aug 2017 07:53:48 +0200
From:   Ivan Delalande <colona@...sta.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 2/2] tcp_diag: report TCP MD5 signing keys
 and addresses

On Fri, Aug 25, 2017 at 08:41:25PM -0700, Eric Dumazet wrote:
> On Fri, 2017-08-25 at 18:53 -0700, Ivan Delalande wrote:
> > Report TCP MD5 (RFC2385) signing keys, addresses and address prefixes to
> > processes with CAP_NET_ADMIN requesting INET_DIAG_INFO. Currently it is
> > not possible to retrieve these from the kernel once they have been
> > configured on sockets.
> 
> ...
> 
> > +static int inet_diag_put_md5sig(struct sk_buff *skb,
> > +				const struct tcp_md5sig_info *md5sig)
> > +{
> > +	const struct tcp_md5sig_key *key;
> > +	struct nlattr *attr;
> > +	struct tcp_md5sig *info;
> > +	int md5sig_count = 0;
> > +
> > +	hlist_for_each_entry_rcu(key, &md5sig->head, node)
> > +		md5sig_count++;
> > +
> > +	attr = nla_reserve(skb, INET_DIAG_MD5SIG,
> > +			   md5sig_count * sizeof(struct tcp_md5sig));
> > +	if (!attr)
> > +		return -EMSGSIZE;
> > +
> > +	info = nla_data(attr);
> > +	hlist_for_each_entry_rcu(key, &md5sig->head, node) {
> > +		inet_diag_md5sig_fill(info, key);
> > +		info++;
> > +	}
> > +
> > +	return 0;
> > +}
> > +#endif
> 
> Unless I missed something, I am sure I gave a feedback on this function
> already :/

Sorry, I probably should have detailed my changes. I tried to address
this by locking the whole socket in the caller, tcp_diag_get_aux, just
outside of the rcu_read_lock. Would this work here, or do you see a
better way?

Thanks for your feedback,
-- 
Ivan Delalande
Arista Networks