netdev - mc_loop and multicast traffic with IPv6 over IPv4 tunnels

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: <200805062358.25834.opurdila@ixiacom.com>
Date:	Tue, 6 May 2008 23:58:25 +0300
From:	Octavian Purdila <opurdila@...acom.com>
To:	netdev@...r.kernel.org
Subject: mc_loop and multicast traffic with IPv6 over IPv4 tunnels

Hi,

We are using a GRE tunnel module developed in house which can tunnel IPv6 
traffic over IPv4. The implementation is similar with what the upstream 
kernel does with GRE, IPIP or SIT tunnels, basically it stuffs the skb with 
the outer header and NF_HOOKs back to the stack. 

I've noticed that when using raw6 sockets on these tunnels, the 
IPV6_MULTICAST_LOOP setsockopt does not take effect, i.e. even if I set 
mc_loop to 0, I still get the send packets back when using a multicast 
address.

This problem seems to be caused by the fact that the when the skb is pushed 
through the tunnel it reaches the IPv4 layer which checks the mc_loop flag 
from the IPv4 part of the socket, which was not altered by the IPv6 
setsockopt. Modifying the IPv4's mc_loop as well in the IPv6's setsockopt 
seems to fix the problem.

I've looked over the upstream kernel GRE, IPIP and SIT tunnel code, and it 
seems that this case is not handled. I'll try to reproduce the problem with 
the upstream kernel as well, but in the meanwhile can somebody tell me if 
there is something obvious that I've missed?

Thanks,
tavi
--
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