netdev - Re: [PATCH net-next 06/15] ipv4: Merge ip_local_out and ip_local_out

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

Date:	Wed, 07 Oct 2015 15:39:52 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Nicolas Dichtel <nicolas.dichtel@...nd.com>
Cc:	David Miller <davem@...emloft.net>,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org,
	lvs-devel@...r.kernel.org, Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH net-next 06/15] ipv4: Merge ip_local_out and ip_local_out_sk

Nicolas Dichtel <nicolas.dichtel@...nd.com> writes:

> Le 06/10/2015 20:53, Eric W. Biederman a écrit :
>> It is confusing and silly hiding a paramater so modify all of
>> the callers to pass in the appropriate socket or skb->sk if
>> no socket is known.
>>
>> Signed-off-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>> ---
> [snip]
>> @@ -456,7 +456,7 @@ packet_routed:
>>   	skb->priority = sk->sk_priority;
>>   	skb->mark = sk->sk_mark;
>>
>> -	res = ip_local_out(skb);
>> +	res = ip_local_out(sk, skb);
> As stated in the comment at the top of this function (ip_queue_xmit()), skb->sk
> can be different from sk. See also commit b0270e91014d ("ipv4: add a sock
> pointer to ip_queue_xmit()").
> Not sure if this change is right.

Good catch.  This change should not have been buried in this patch. It
needs to be it's own separate bug fix.

As I read the code we actually do want to pass sk not skb->sk into
ip_local_out.  For all of the reasons that sk is potentially different
from skb->sk already.

The way I understand this is we have pushed an sk parameter through the
output path so that sk_mc_loop(sk) can be called with the tunnel's
socket not whatever is on skb->sk.  This allows for looking to see if
local multicast loopback is configured on the tunnels socket not on the
originating socket of the packet.

I am going to respin my series with that change made into a separate bug
fix, that can potentially be backported.

Eric

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