netdev - [PATCH] af_packet: po->mclist needs locker in reader side(WAS: [PATCH 1/9] af_packet: Check return of dev_set

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: <487C573F.3020803@cn.fujitsu.com>
Date:	Tue, 15 Jul 2008 15:52:31 +0800
From:	Wang Chen <wangchen@...fujitsu.com>
To:	David Miller <davem@...emloft.net>
CC:	kaber@...sh.net, netdev@...r.kernel.org
Subject: [PATCH] af_packet: po->mclist needs locker in reader side(WAS: [PATCH
 1/9] af_packet: Check return of dev_set_promiscuity/allmulti)

David Miller said the following on 2008-7-15 11:51:
> From: Wang Chen <wangchen@...fujitsu.com>
> Date: Tue, 15 Jul 2008 10:59:09 +0800
> 
>> dev_set_promiscuity/allmulti might overflow.
>> Commit: "netdevice: Fix promiscuity and allmulti overflow" in net-next makes
>> dev_set_promiscuity/allmulti return error number if overflow happened.
>>
>> In af_packet, we check all positive increment for promiscuity and allmulti
>> to get error return.
>>
>> Signed-off-by: Wang Chen <wangchen@...fujitsu.com>
>> Acked-by: Patrick McHardy <kaber@...sh.net> 
> 
> Applied, thanks.
> 
> What are the exact locking rules for po->mclist btw?  Obviously
> changes to the list are RTNL protected, but what about readers?
> 
> If readers lock differently, this error recovery where we unlink 'i'
> could cause an OOPS.  It is ok to add new elements while allowing
> readers to traverse independantly but removal needs to interlock with
> such readers.

As my understanding, packet_dev_mclist() is the only reader who doesn't
use same lock as writers(actually it doesn't use any lock).
My proposal is that use RTNL to prevent synchronous access to po->mclist.
Because packet_dev_mclist() is only called when device be unregistered,
the lock will not affect speed too much. 

Signed-off-by: Wang Chen <wangchen@...fujitsu.com>
---
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 2cee87d..9eb39f7 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1196,10 +1196,12 @@ static void packet_dev_mc(struct net_device *dev, struct packet_mclist *i, int w
 
 static void packet_dev_mclist(struct net_device *dev, struct packet_mclist *i, int what)
 {
+	rtnl_lock();
 	for ( ; i; i=i->next) {
 		if (i->ifindex == dev->ifindex)
 			packet_dev_mc(dev, i, what);
 	}
+	rtnl_unlock();
 }
 
 static int packet_mc_add(struct sock *sk, struct packet_mreq_max *mreq)

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html