diff options
| author | Xin Long <lucien.xin@gmail.com> | 2020-04-21 20:46:11 +0800 |
|---|---|---|
| committer | Steffen Klassert <steffen.klassert@secunet.com> | 2020-04-23 08:02:31 +0200 |
| commit | 976eba8ab596bab94b9714cd46d38d5c6a2c660d (patch) | |
| tree | d59cbb291980440a8656187cdd8930e35e749b08 /net/xfrm | |
| parent | a204aef9fd77dce1efd9066ca4e44eede99cd858 (diff) | |
| download | lwn-976eba8ab596bab94b9714cd46d38d5c6a2c660d.tar.gz lwn-976eba8ab596bab94b9714cd46d38d5c6a2c660d.zip | |
ip_vti: receive ipip packet by calling ip_tunnel_rcv
In Commit dd9ee3444014 ("vti4: Fix a ipip packet processing bug in
'IPCOMP' virtual tunnel"), it tries to receive IPIP packets in vti
by calling xfrm_input(). This case happens when a small packet or
frag sent by peer is too small to get compressed.
However, xfrm_input() will still get to the IPCOMP path where skb
sec_path is set, but never dropped while it should have been done
in vti_ipcomp4_protocol.cb_handler(vti_rcv_cb), as it's not an
ipcomp4 packet. This will cause that the packet can never pass
xfrm4_policy_check() in the upper protocol rcv functions.
So this patch is to call ip_tunnel_rcv() to process IPIP packets
instead.
Fixes: dd9ee3444014 ("vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel")
Reported-by: Xiumei Mu <xmu@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Diffstat (limited to 'net/xfrm')
0 files changed, 0 insertions, 0 deletions