net: ipv4: current group_info should be put after using.

This is a typical refcount leak exploitable by unprivileged users. Current group_info had been got in ping_init_sock and group_info->usage increased. But the usage hasn't decreased anywhere in ping. This will make this group_info never freed.

---
 net/ipv4/ping.c |   15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)

index f4b19e5..8210964 100644
@@ -252,26 +252,33 @@ int ping_init_sock(struct sock *sk)
 {
 	struct net *net = sock_net(sk);
 	kgid_t group = current_egid();
-	struct group_info *group_info = get_current_groups();
-	int i, j, count = group_info->ngroups;
+	struct group_info *group_info;
+	int i, j, count;
 	kgid_t low, high;
+	int ret = 0;
 
 	inet_get_ping_group_range_net(net, &low, &high);
 	if (gid_lte(low, group) && gid_lte(group, high))
 		return 0;
 
+	group_info = get_current_groups();
+	count = group_info->ngroups;
 	for (i = 0; i < group_info->nblocks; i++) {
 		int cp_count = min_t(int, NGROUPS_PER_BLOCK, count);
 		for (j = 0; j < cp_count; j++) {
 			kgid_t gid = group_info->blocks[i][j];
 			if (gid_lte(low, gid) && gid_lte(gid, high))
-				return 0;
+				goto out_release_group;
 		}
 
 		count -= cp_count;
 	}
 
-	return -EACCES;
+	ret = -EACCES;
+
+out_release_group:
+	put_group_info(group_info);
+	return ret;
 }
 EXPORT_SYMBOL_GPL(ping_init_sock);
 

1.7.1

The patch is fine, however I had a brainfart with my last sentence about commit message, sorry for that.

group_info *can be freed* by malicious user while still being pointed to by something, that's the biggest problem with refcount leaks, therefore this message needs some reworking.

I think that discussion about various consequences of refcount leak in commit message is not necessary.

how about:

Plug a group_info refcount leak in ping_init.

group_info is only needed during initialization and the code failed to release the reference on exit.

While here move grabbing the reference to a place where it is actually needed.

====

Please cc: me if you resend the patch.

Thanks,

Mateusz Guzik

From: Mateusz Guzik <[email protected]>
Date: Fri, 11 Apr 2014 15:50:27 +0200

Never resubmit a patch as a reply to a thread discussion a previous version of the patch if you want it to be considered for inclusion.

Always make a new, fresh, mailing list posting properly formated for a patch submission and with out any unrelated material in the email message.

Thanks.