Date: Fri, 30 Jun 2023 08:37:58 -0700
From: "Maciej Żenczykowski" <maze@...gle.com>
To: "Maciej Żenczykowski" <zenczykowski@...il.com>
Cc: Linux Network Development Mailing List <netdev@...r.kernel.org>, 
	"Maciej Żenczykowski" <maze@...gle.com>, Herbert Xu <herbert@...dor.apana.org.au>, 
	Steffen Klassert <steffen.klassert@...unet.com>, Benedict Wong <benedictwong@...gle.com>, 
	Lorenzo Colitti <lorenzo@...gle.com>, Yan Yan <evitayan@...gle.com>
Subject: [PATCH] FYI 6.4 xfrm_prepare_input/xfrm_inner_mode_encap_remove
 WARN_ON hit - related to ESPinUDP

Steffan, this isn't of course a patch meant for inclusion, instead just a WARN_ON hit report.
The patch is simply what prints the following extra info:

xfrm_prepare_input: XFRM_MODE_SKB_CB(skb)->protocol: 17
xfrm_inner_mode_encap_remove: x->props.mode: 1 XFRM_MODE_SKB_SB(skb)->protocol:17

(note: XFRM_MODE_TUNNEL=1 IPPROTO_UDP=17)

Hit on Linux 6.4 by:
  https://cs.android.com/android/platform/superproject/+/master:kernel/tests/net/test/xfrm_test.py

likely related to line 230:
  encap_sock.setsockopt(IPPROTO_UDP, xfrm.UDP_ENCAP, xfrm.UDP_ENCAP_ESPINUDP)

I'm not the author of these tests, and I know very little about XFRM.
As such, I'm not sure if there isn't a bug in the tests themselves...
maybe we're generating invalid packets that aren't meant to be decapsulated???

Or are we missing some sort of assignment inside of the ESP in UDP decap codepath?

Somewhere in the vicinity of xfrm4_udp_encap_rcv / xfrm4_rcv_encap
(and the v6 equivalents)

$ git log --decorate --oneline --graph -n 3
* c1ae64591391 (HEAD) FYI 6.4 xfrm_prepare_input/xfrm_inner_mode_encap_remove WARN_ON hit - related to ESPinUDP
* da2779e6377a ANDROID: net: xfrm: make PF_KEY SHA256 use RFC-compliant truncation.  [trivial: .icv_truncbits = 96 -> 128 -- just ignore it]
* 6995e2de6891 (tag: remotes/linux/v6.4) Linux 6.4

Full call stack from running the Android net test suite on a 6.4 UML via:
  ARCH=um SUBARCH=x86_64 /aosp-tests/net/test/run_net_test.sh --builder all_tests.sh

*#### ./xfrm_test.py (11/24)

.........xfrm_prepare_input: XFRM_MODE_SKB_CB(skb)->protocol: 17
------------[ cut here ]------------
WARNING: CPU: 0 PID: 326 at net/xfrm/xfrm_input.c:380 xfrm_input+0x7fc/0x115d
Modules linked in:
CPU: 0 PID: 326 Comm: xfrm_test.py Not tainted 6.4.0-gc1ae64591391 #8
Stack:
 604bc85a 605bc4ee 818ef5b0 604a3aea
 818ef650 605bc4ee 60037b59 604bc85a
 00000001 605ae79b 818ef5e0 604c3327
Call Trace:
 [<604bc85a>] ? _printk+0x0/0x94
 [<60025a79>] show_stack+0x113/0x18b
 [<604bc85a>] ? _printk+0x0/0x94
 [<604a3aea>] ? dump_stack_print_info+0xe1/0xf0
 [<60037b59>] ? um_set_signals+0x0/0x3e
 [<604bc85a>] ? _printk+0x0/0x94
 [<604c3327>] dump_stack_lvl+0x4a/0x58
 [<604c32dd>] ? dump_stack_lvl+0x0/0x58
 [<60041747>] ? check_panic_on_warn+0x0/0x6f
 [<604c334f>] dump_stack+0x1a/0x1c
 [<600419b4>] __warn+0xcd/0x118
 [<604bbc1e>] warn_slowpath_fmt+0xe4/0xf2
 [<604bbb3a>] ? warn_slowpath_fmt+0x0/0xf2
 [<604bc85a>] ? _printk+0x0/0x94
 [<603e2958>] ? esp_input+0x28f/0x2ac
 [<603fbae9>] ? xfrm_aevent_is_on+0x21/0x26
 [<603fc087>] ? xfrm_replay_advance+0xf2/0x26a
 [<603f99cf>] xfrm_input+0x7fc/0x115d
 [<6040334e>] xfrmi_input+0xa3/0xb2
 [<60403373>] xfrmi4_input+0x16/0x18
 [<603eb9f0>] xfrm4_rcv_encap+0xb5/0xea
 [<603eb102>] ? xfrm4_dst_destroy+0x67/0xeb
 [<603eb39c>] xfrm4_udp_encap_rcv+0x1c6/0x1e6
 [<603eb1d6>] ? xfrm4_udp_encap_rcv+0x0/0x1e6
 [<603b60f8>] udp_queue_rcv_one_skb+0x77/0x339
 [<603b7957>] udp_queue_rcv_skb+0x5c/0x298
 [<603b7c01>] udp_unicast_rcv_skb+0x6e/0x7c
 [<603b962a>] __udp4_lib_rcv+0x613/0x6fe
 [<603b3641>] ? raw_local_deliver+0x0/0x1c7
 [<603b9a0c>] udp_rcv+0x27/0x29
 [<603809eb>] ip_protocol_deliver_rcu+0x77/0x104
 [<60380b4c>] ip_local_deliver_finish+0xd4/0xdb
 [<60380a78>] ? ip_local_deliver_finish+0x0/0xdb
 [<6037fe91>] NF_HOOK.constprop.0+0x76/0x81
 [<60380a78>] ? ip_local_deliver_finish+0x0/0xdb
 [<6037feed>] ip_local_deliver+0x51/0x72
 [<60380371>] ? ip_rcv_finish+0x0/0x3d
 [<603803a9>] ip_rcv_finish+0x38/0x3d
 [<6037fe91>] NF_HOOK.constprop.0+0x76/0x81
 [<60380371>] ? ip_rcv_finish+0x0/0x3d
 [<60380b9e>] ip_rcv+0x4b/0x50
 [<60318d32>] __netif_receive_skb_one_core+0x46/0x4d
 [<60318da2>] __netif_receive_skb+0x55/0x5c
 [<60318df4>] netif_receive_skb+0x4b/0x4f
 [<602c9838>] tun_rx_batched+0x199/0x1b4
 [<602cf02e>] tun_get_user+0xba5/0xcd8
 [<6003a100>] ? userspace_tramp+0x1a6/0x242
 [<60039b1c>] ? do_syscall_stub+0xfa/0x24a
 [<602cf1d7>] tun_chr_write_iter+0x76/0x9a
 [<601410aa>] new_sync_write+0x8f/0x101
 [<601423d2>] vfs_write+0xe7/0x12a
 [<6016239e>] ? __fdget_pos+0x12/0x4c
 [<60142555>] ksys_write+0x79/0xb5
 [<601425a1>] sys_write+0x10/0x12
 [<60027b34>] handle_syscall+0x79/0xa7
 [<6003a9af>] userspace+0x4cf/0x60f
 [<600248bf>] fork_handler+0x92/0x94
---[ end trace 0000000000000000 ]---
xfrm_inner_mode_encap_remove: x->props.mode: 1 XFRM_MODE_SKB_SB(skb)->protocol:17
------------[ cut here ]------------
WARNING: CPU: 0 PID: 326 at net/xfrm/xfrm_input.c:352 xfrm_input+0xf2f/0x115d
...

Cc: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@...unet.com>
Cc: Benedict Wong <benedictwong@...gle.com>
Cc: Lorenzo Colitti <lorenzo@...gle.com>
Cc: Yan Yan <evitayan@...gle.com>
---
 net/xfrm/xfrm_input.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 815b38080401..bd10605b211d 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -348,6 +348,7 @@ xfrm_inner_mode_encap_remove(struct xfrm_state *x,
 		}
 	}
 
+	printk(KERN_WARNING "xfrm_inner_mode_encap_remove: x->props.mode: %d XFRM_MODE_SKB_SB(skb)->protocol:%d\n", x->props.mode, XFRM_MODE_SKB_CB(skb)->protocol);
 	WARN_ON_ONCE(1);
 	return -EOPNOTSUPP;
 }
@@ -375,6 +376,7 @@ static int xfrm_prepare_input(struct xfrm_state *x, struct sk_buff *skb)
 		skb->protocol = htons(ETH_P_IPV6);
 		break;
 	default:
+		printk(KERN_WARNING "xfrm_prepare_input: XFRM_MODE_SKB_CB(skb)->protocol: %d\n", XFRM_MODE_SKB_CB(skb)->protocol);
 		WARN_ON_ONCE(1);
 		break;
 	}
-- 
2.41.0.255.g8b1d071c50-goog

Powered by blists - more mailing lists