| Message ID | 6d1bc4971f1095fcd277714e827c52882fa2c9b1.1616149678.git.lucien.xin@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [ipsec] xfrm: BEET mode doesn't support fragments for inner packets | expand |
On Fri, Mar 19, 2021 at 06:27:58PM +0800, Xin Long wrote: > BEET mode replaces the IP(6) Headers with new IP(6) Headers when sending > packets. However, when it's a fragment before the replacement, currently > kernel keeps the fragment flag and replace the address field then encaps > it with ESP. It would cause in RX side the fragments to get reassembled > before decapping with ESP, which is incorrect. > > In Xiumei's testing, these fragments went over an xfrm interface and got > encapped with ESP in the device driver, and the traffic was broken. > > I don't have a good way to fix it, but only to warn this out in dmesg. Looks like a protocol bug. BEET mode never made it to a standard... > > Reported-by: Xiumei Mu <xmu@redhat.com> > Signed-off-by: Xin Long <lucien.xin@gmail.com> Applied, thanks!
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c index b81ca11..e4cb0ff 100644 --- a/net/xfrm/xfrm_output.c +++ b/net/xfrm/xfrm_output.c @@ -660,6 +660,12 @@ static int xfrm4_extract_output(struct xfrm_state *x, struct sk_buff *skb) { int err; + if (x->outer_mode.encap == XFRM_MODE_BEET && + ip_is_fragment(ip_hdr(skb))) { + net_warn_ratelimited("BEET mode doesn't support inner IPv4 fragments\n"); + return -EAFNOSUPPORT; + } + err = xfrm4_tunnel_check_size(skb); if (err) return err; @@ -705,8 +711,15 @@ static int xfrm6_tunnel_check_size(struct sk_buff *skb) static int xfrm6_extract_output(struct xfrm_state *x, struct sk_buff *skb) { #if IS_ENABLED(CONFIG_IPV6) + unsigned int ptr = 0; int err; + if (x->outer_mode.encap == XFRM_MODE_BEET && + ipv6_find_hdr(skb, &ptr, NEXTHDR_FRAGMENT, NULL, NULL) >= 0) { + net_warn_ratelimited("BEET mode doesn't support inner IPv6 fragments\n"); + return -EAFNOSUPPORT; + } + err = xfrm6_tunnel_check_size(skb); if (err) return err;
BEET mode replaces the IP(6) Headers with new IP(6) Headers when sending packets. However, when it's a fragment before the replacement, currently kernel keeps the fragment flag and replace the address field then encaps it with ESP. It would cause in RX side the fragments to get reassembled before decapping with ESP, which is incorrect. In Xiumei's testing, these fragments went over an xfrm interface and got encapped with ESP in the device driver, and the traffic was broken. I don't have a good way to fix it, but only to warn this out in dmesg. Reported-by: Xiumei Mu <xmu@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> --- net/xfrm/xfrm_output.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)