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
| ||
|
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
Powered by blists - more mailing lists