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]
Date:	Sun, 27 Mar 2011 05:44:04 +0200
From:	Linus Lüssing <linus.luessing@....de>
To:	bridge@...ts.linux-foundation.org
Cc:	Stephen Hemminger <shemminger@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	netdev@...r.kernel.org
Subject: Checksumming bug in bridge multicast snooping for IPv6?

Hi everyone,

Somehow I'm having trouble with the IPv6 bridge snooping again:
MLDv2 Reports are dropped by the multicast snooping feature, looks
like it has something to do with checksums. Wireshark does not
display any weirdness, it at least reports the MLD reports
checksum as correct.


The setup is the following: The VM is running a current Linux
version of torvalds branch with no other additions then the
printk-debug patch attached (2.6.38+ #4 SMP PREEMPT Sat Mar 26
22:59:11 GMT 2011 i686 GNU/Linux):
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;h=16c29dafcc86024048f1dbb8349d31cb22c7c55a;hb=16c29dafcc86024048f1dbb8349d31cb22c7c55a
The host machine which is joining a multicast group is doing an
explicit join on the KVM instances provided tap interface:
IPv6: vlc -vvv "udp://@[ff12::124%vmtap1]"
(IPv4: vlc -vvv "udp://@....0.1.123")
The host machine is running a kernel from Debian unstable:
2.6.37-2-amd64 #1 SMP Sun Feb 27 12:32:01 UTC 2011 x86_64
GNU/Linux

See the attached debug patch and the according output for some
more details where it fails (the bridge is basically ignoring the
MLDv2 report due to the goto in this line:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=net/bridge/br_multicast.c;h=f61eb2eff3fdd387b83d9fab642bb610dde1ad69;hb=HEAD#l1530)

I'm also attaching both a wireshark capture of the ignored IPv6
MLDv2 report and the working IGMPv3 report, which correspond
directly to the attached printk debug output.


I'm a little bit startled because I definitely had that part
working a couple of weeks ago and I'm still trying to figure out
what I might have changed in the setup. I definitely have updated
the VMs kernel, but the same issue is present for the 2.6.38 and
also 2.6.37 release versions with my fixes backported 
(the latter one was the one I had been using back then).
I probably have updated the multicast listener host's kernel, too,
I might have been running 2.6.32 or something more earlier... I've
also tried having the listener host in another VM with the same
2.6.38+ kernel as the bridge-snooping host, but also that did not
make a difference.


Anyways, skb_checksum_complete() is calculating the checksum from
skb's data to tail pointer, right?
RFC3810 for MLDv2, section 5.1.2 says:
"The standard ICMPv6 checksum; it covers the entire MLDv2 message,
plus a "pseudo-header" of IPv6 header fields [RFC2463]."
Could it be that this "pseudo-header" is not included in the
checksumming? Is there a function in the kernel which could
already provide that?
I guess that could also explain why it's working fine for IPv4,
there it's just the IGMP message being checksummed according to
RFC 3376, section 4.1.2.


Cheers, Linus


PS: There also seems to be another offset bug in the same
function, see comment in debug patch file, though seemingly
unrelated to the issue described above. Correcting that
len-variable does to help for the above issue. 

View attachment "br-mcast-snoop-printk-debug.log" of type "text/plain" (1839 bytes)

View attachment "bridge-snoop-debug.patch" of type "text/x-diff" (4954 bytes)

Download attachment "ipv4-group-join.cap" of type "application/cap" (164 bytes)

Download attachment "ipv6-group-join.cap" of type "application/cap" (236 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ