netdev - [PATCH] vlan: fix potential race in vlan_cleanup_module vs vlan_ioctl

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-next>] [day] [month] [year] [list]

Message-ID: <475E6587.1090306@openvz.org>
Date:	Tue, 11 Dec 2007 13:25:11 +0300
From:	Pavel Emelyanov <xemul@...nvz.org>
To:	David Miller <davem@...emloft.net>,
	Patrick McHardy <kaber@...sh.net>
CC:	Linux Netdev List <netdev@...r.kernel.org>, devel@...nvz.org
Subject: [PATCH] vlan: fix potential race in vlan_cleanup_module vs vlan_ioctl_handler

The vlan module cleanup function starts with

	vlan_netlink_fini();
	vlan_ioctl_set(NULL);

The first call removes all the vlan devices and
the second one closes the vlan ioctl.

AFAIS there's a tiny race window between these two
calls - after rtnl unregistered all the vlans, but 
the ioctl handler isn't set to NULL yet, user can 
manage to call this ioctl and create one vlan device, 
and that this function will later BUG_ON seeing 
non-emply hashes.

I think, that we must first close the vlan ioctl
and only after this remove all the vlans with the
vlan_netlink_fini() call.

Signed-off-by: Pavel Emelyanov <xemul@...nvz.org>

---

diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 5b18315..4add9bd 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -124,8 +124,8 @@ static void __exit vlan_cleanup_module(void)
 {
 	int i;

-	vlan_netlink_fini();
 	vlan_ioctl_set(NULL);
+	vlan_netlink_fini();

 	/* Un-register us from receiving netdevice events */
 	unregister_netdevice_notifier(&vlan_notifier_block);
--
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