summaryrefslogtreecommitdiffstats
path: root/net/vmw_vsock
diff options
context:
space:
mode:
authorFlorian Westphal <fw@strlen.de>2018-10-10 17:25:47 +0200
committerPablo Neira Ayuso <pablo@netfilter.org>2018-10-16 10:01:49 +0200
commit1321a6af30e45e467d0a5da00e8480c48cb627ee (patch)
tree9c462f53007ae4363d404d07d28b85cde8da7bb0 /net/vmw_vsock
parenta218dc82f0b5c6c8ad3d58c9870ed69e26c08b3e (diff)
downloadlinux-1321a6af30e45e467d0a5da00e8480c48cb627ee.tar.bz2
netfilter: nft_xfrm: use state family, not hook one
Eyal says: doesn't the use of nft_pf(pkt) in this context limit the matching of encapsulated packets to the same family? IIUC when an e.g. IPv6-in-IPv4 packet is matched, the nft_pf(pkt) will be the decapsulated packet family - IPv6 - whereas the state may be IPv4. So this check would not allow matching the 'underlay' address in such cases. I know this was a limitation in xt_policy. but is this intentional in this matcher? or is it possible to use state->props.family when validating the match instead of nft_pf(pkt)? Userspace already tells us which address family it expects to match, so we can just use the real state family rather than the hook family. so change it as suggested above. Reported-by: Eyal Birger <eyal.birger@gmail.com> Suggested-by: Eyal Birger <eyal.birger@gmail.com> Fixes: 6c47260250fc6 ("netfilter: nf_tables: add xfrm expression") Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Diffstat (limited to 'net/vmw_vsock')
0 files changed, 0 insertions, 0 deletions