netdev - Re: [PATCH net-next v2 2/5] mpls: Remove incorrect PHP comment

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:	Mon, 23 Mar 2015 13:16:41 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Robert Shearman <rshearma@...cade.com>
Cc:	"davem\@davemloft.net" <davem@...emloft.net>,
	"netdev\@vger.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v2 2/5] mpls: Remove incorrect PHP comment

Robert Shearman <rshearma@...cade.com> writes:

> On 22/03/15 19:12, Eric W. Biederman wrote:
>> Robert Shearman <rshearma@...cade.com> writes:
>>
>>> Popping the last label on the stack does not necessarily imply
>>> performing penultimate hop popping. There is no reason why this
>>> couldn't be the last hop in the network, so remove the comment.
>>
>> So this change I will disagree with.
>>
>> What the code implements is Penultimate hop popping.  Even if you send
>> the packets over loopback that is what the code is doing.
>
> No, RFC3031 s3.16 (https://tools.ietf.org/html/rfc3031#page-18) talks in terms
> of LSRs (label switch routers), not passes through the forwarding
> code.

In very simple terms the code always removes the labels and forwards the
code.  That is by definition penultimate hop popping.  That is all that
is implmeneted in the code today.  And that is what the comment is
noting.

>> This is relevant because I think the code may actually be wrong in the
>> local reception case.  By preforming penultimate hop popping and
>> receving the code on loopback I think this code allows bypassing
>> iptables rules that apply to incoming ip packets.  Certainly there is a
>> loss of information as to which hardware interface the packet came in on
>> that it may be desirable to correct.
>
> Indeed, but network operators may well want to apply different rules to traffic
> coming in as IP versus traffic coming in as MPLS.
>
> This may well merit a comment of its own, but this isn't directly relevant to
> the comment I'm removing.

My point is and what is directly relevant is the case of local delivery
is a hack.  A hack that a pretty strong case can be made that it does
the wrong thing and something we probably should fix before the code
makes it to Linus for 4.1 so the bug does not get cast in stone.

In other words the disparity between the comment and the code indicates
an actual bug, not just a wrong comment.

Eric

>>> Cc: "Eric W. Biederman" <ebiederm@...ssion.com>
>>> Signed-off-by: Robert Shearman <rshearma@...cade.com>
>>> ---
>>>   net/mpls/af_mpls.c | 1 -
>>>   1 file changed, 1 deletion(-)
>>>
>>> diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
>>> index 0d6763a..bf3459a 100644
>>> --- a/net/mpls/af_mpls.c
>>> +++ b/net/mpls/af_mpls.c
>>> @@ -199,7 +199,6 @@ static int mpls_forward(struct sk_buff *skb, struct net_device *dev,
>>>   	skb->protocol = htons(ETH_P_MPLS_UC);
>>>
>>>   	if (unlikely(!new_header_size && dec.bos)) {
>>> -		/* Penultimate hop popping */
>>>   		if (!mpls_egress(rt, skb, dec))
>>>   			goto drop;
>>>   	} else {
--
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