netdev - Re: [PATCH] FYI 6.4 xfrm_prepare_input/xfrm_inner_mode_encap_remove WARN_ON hit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 30 Jun 2023 19:05:48 +0200
From: Maciej Żenczykowski <zenczykowski@...il.com>
To: Maciej Żenczykowski <zenczykowski@...il.com>
Cc: Linux Network Development Mailing List <netdev@...r.kernel.org>, 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: Re: [PATCH] FYI 6.4 xfrm_prepare_input/xfrm_inner_mode_encap_remove
 WARN_ON hit - related to ESPinUDP

On Fri, Jun 30, 2023 at 5:38 PM Maciej Żenczykowski <maze@...gle.com> 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 <herbert@...dor.apana.org.au>
    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