netdev - R: Re: BUG (?) multicast loopback (IP6SKB

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

Message-ID: <3948604.8447911339409358263.JavaMail.defaultUser@defaultHost>
Date:	Mon, 11 Jun 2012 12:09:18 +0200 (CEST)
From:	"maxd@...ind.it" <maxd@...ind.it>
To:	<eric.dumazet@...il.com>
Cc:	<netdev@...r.kernel.org>
Subject: R: Re: BUG (?) multicast loopback (IP6SKB_FORWARDED)

Hi Eric,
thanks for the quick reply. It seems that reverting the patch fixes the issue, 
and I have not observed any unintended behaviour so far.
Do you know what was the motivation for the patch?

Regards,
Massimiliano

>----Messaggio originale----
>Da: eric.dumazet@...il.com
>Data: 08/06/2012 19.23
>A: "maxd@...ind.it"<maxd@...ind.it>
>Cc: <netdev@...r.kernel.org>
>Ogg: Re: BUG (?) multicast loopback (IP6SKB_FORWARDED)
>
>On Fri, 2012-06-08 at 18:48 +0200, maxd@...ind.it wrote:
>> Hi guys,
>> I found a probably wrong behaviour while doing some tests with multicast 
>> routing on IPv6 with kernel 2.6.29. I will try to describe what's wrong in 
the 
>> code in the following. I will use the latest kernel sources (3.5-rc1)
>> as reference source code (line numbers are taken there).
>> Let's assume a scenario with a node with two network interfaces acting as 
a 
>> multicast router. The router receives the message on one interface and 
needs to 
>> forward it on the other interface. Looking at the packet flow inside the 
>> kernel, we notice that
>> 
>> in ip6mr.c, line 2282, a flag is set:
>> IP6CB(skb)->flags |= IP6SKB_FORWARDED;
>> 
>> After this, a multicast packet can be looped back (see line 124 in 
ip6_output.
>> c where function ip6_dev_loopback_xmit is called). 
>> The packet is hence reinjected in the stack.
>> 
>> The packet is processed by function ipv6_rcv (ip6_input.c), and then by 
>> ipv6_mc_input (ip6_input.c).
>> 
>> In ipv6_rcv, line 82, the previously set flag is cleared
>> memset(IP6CB(skb), 0, sizeof(struct inet6_skb_parm));
>> 
>> In ipv6_mc_input, , line 268, the flag is checked to determine if the 
packet 
>> has been already forwarded. Since the flag has been cleared, the kernel 
cannot 
>> determine that the packet has been looped back, and will hence try to 
forward 
>> it again.
>> 
>> Trying to forward a looped back packet determines a wrong behaviour of the 
>> multicast routing protocol (PIM): the kernel believes that a multicast 
message 
>> has been received from a wrong interface (line 1993 in ip6mr.c), discard 
the 
>> message (this explains why the packet does not loop forever) and triggers 
the 
>> transmission of an ASSERT message. Basically, the node ends up sending an 
>> ASSERT message because of a looped back packet. 
>> 
>> WDYT? Is my analysis correct? Which is the best way to fix this issue?
>
>I guess your analysis is correct, try to revert commit
>6b7fdc3ae18a0598a999156b62d55ea55220e00f ([IPV6]: Clean skb cb on IPv6
>input) ?
>
>
>
>--
>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
>


--
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