netdev - Re: [net PATCH] ip_vti/ip6_vti: Clear skb->mark when resetting skb->dev in receive path

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, 13 May 2015 23:14:39 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>,
	Alexander Duyck <alexander.h.duyck@...hat.com>
CC:	netdev@...r.kernel.org, steffen.klassert@...unet.com,
	tgraf@...g.ch, davem@...emloft.net
Subject: Re: [net PATCH] ip_vti/ip6_vti: Clear skb->mark when resetting skb->dev
 in receive path

On 05/13/2015 08:28 PM, Herbert Xu wrote:
> On Wed, May 13, 2015 at 07:04:28PM -0700, Alexander Duyck wrote:
>> This change makes it so that we clear the skb->mark field when we pass
>> through the receive path of the IPv4 or IPv6 virtual tunnel interface.  The
>> reason for clearing these fields is to resolve an apparent regression for
>> the behavior before skb_scrub_packet was modified.  Without this patch I
>> have to set disable_policy for the vti tunnel endpoint in order to be able
>> to receive traffic.
>>
>> Fixes: 213dd74aee76 ("skbuff: Do not scrub skb mark within the same name space")
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@...hat.com>
> This patch makes no sense.  Please explain your problem more
> clearly and tell us why the mark changes the way your packet
> is dealt with and why this isn't a policy decision that should
> be made in user-space.
>
> Cheers,

The problem is if I set up a ipsec tunnel with vti endpoints on the 
current net-next I am unable to ping the other side.  What it looks like 
is the packet makes it past the endpoint (I can see the ICMP request in 
tcpdump), but the stack appears to be dropping the frame due to a policy 
check.  With my patch applied this issue is resolved, same thing for if 
I revert the "Fixes" patch, or if I set disable_policy for the vti endpoint.

The fact is I am not all that familiar with the vti code and just 
started crawling through it a few days ago, but it seems like it is 
overwriting the skb->mark value with the i_key to determine which policy 
to use.  The code prior to commit df3893c176e9 ("vti: Update the ipv4 
side to use it's own receive hook.") was saving the old skb->mark, 
overwriting it, and then restoring it after a call to 
xfrm4_policy_check.  After that commit it was letting skb_scrub_packet 
in vti_rcv_cb clear the mark and it was just dropped.

I suppose if we are wanting to get back to the behavior before the 
receive hook change we could look at maybe storing the previous mark in 
the skb->cb assuming there is any room there for it, and then we could 
restore it in vti_rcv_cb.

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