netdev - Re: [BUG][debian-2.6.20-1-686] bridging + vlans + "vconfig rem" == stuck kernel

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

Date:	Sat, 12 May 2007 08:13:56 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Ben Greear <greearb@...delatech.com>
Cc:	netdev@...r.kernel.org, LKML Kernel <linux-kernel@...r.kernel.org>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	OSDL Linux Bridging <bridge@...l.org>
Subject: Re: [BUG][debian-2.6.20-1-686] bridging + vlans + "vconfig rem" == stuck kernel

On May 11, 2007, at 01:49:27, Kyle Moffett wrote:
> On May 10, 2007, at 00:34:11, Kyle Moffett wrote:
>> On May 10, 2007, at 00:25:54, Ben Greear wrote:
>>> Looks like a deadlock in the vlan code.  Any chance you can run  
>>> this test with lockdep enabled?
>>>
>>> You could also add a printk in vlan_device_event() to check which  
>>> event it is hanging on, and the netdevice that is passed in.
>>
>> Ok, I'll try building a 2.6.21 kernel with lockdep and some  
>> debugging printk()s in the vlan_device_event() function and get  
>> back to you tomorrow.  Thanks for the quick response!

[snip]

> ifup -a brings up the interfaces in this order (See previous email  
> for configuration details):
> lo net0 wfi0 world0 lan lan:0 world
>
> ifdown -a appears to bring them down in the same order (at least,  
> until it gets stuck).

Hmm, turns out that it always hung downing this entry in my  
interfaces file, independent of ordering:

iface world0 inet manual
	mac-address 8b:8d:cb:91:e2:4c
	minimally-up yes
	vlan-dev net0
	vlan-id 4094

By commenting out the MAC address line it worked.  Yes, I realize the  
MAC address specified there is bogus, I managed to {think,type}o that  
one somehow.  I had been intending to specify a locally-allocated  
virtual MAC address on world0 but instead I managed to somehow assign  
one with the MAC multicast bit set (01:00:00:00:00:00)
If I change the above garbage MAC to 02:00:00:00:00:01 (first 02 is  
the locally-administrated bit) then it seems to work perfectly fine,   
My guess that the bridging code doesn't properly drop all references  
to world0 when it has that garbage MAC address on it (since the  
problem only shows up when both the invalid mac-address is present  
*AND* I start the "world" bridge).  I suppose this isn't really a big  
problem, but it would be nice if things didn't leak refcounts on  
invalid input.

Cheers,
Kyle Moffett

-
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