On Fri, Jun 30, 2023 at 5:38 PM Maciej Żenczykowski [off-list ref] wrote:

Steffan, this isn't of course a patch meant for inclusion, instead just a WARN_ON hit report.

Sorry for the name typo (it's Stefan in Polish).

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)

I've done some bisection (well more like educated guesswork)
and the regression (if one should call it that?) is caused by 6.4

commit 5f24f41e8ea62a6a9095f9bbafb8b3aebe265c68
Author: Herbert Xu [off-list ref]
    xfrm: Remove inner/outer modes from input path

The xfrm tests pass either way, but with the above reverted it no
longer triggers the WARN_ON.

$ git log --decorate --oneline --graph -n 3
* da7dc0870b19 (HEAD) Revert "xfrm: Remove inner/outer modes from
input path"  <-- passes, doesn't warn
* 51d5381c5809 ANDROID: net: xfrm: make PF_KEY SHA256 use
RFC-compliant truncation.  <-- passes, does warn
* 5f24f41e8ea6 xfrm: Remove inner/outer modes from input path  <--
passes xfrm, fails pf_key, warns