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 for Android: free password hash cracker in your pocket

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

Message-ID: <CANP3RGemhoHyeki_ZzbX4JAWuCq3YZOOs64=T5YZ0XSaK8wbpA@mail.gmail.com>
Date: Sat, 1 Jul 2023 14:39:36 +0200
From: Maciej Żenczykowski <maze@...gle.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Linux Network Development Mailing List <netdev@...r.kernel.org>, 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 Sat, Jul 1, 2023 at 2:27 PM Maciej Żenczykowski <maze@...gle.com> wrote:
> On Sat, Jul 1, 2023 at 9:51 AM Herbert Xu <herbert@...dor.apana.org.au> wrote:
> > > 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
> >
> > This seems to make no sense.  UDP encapsulation is supposed to sit
> > on the outside of ESP.  So by the time we hit xfrm_input it should
> > be lone gone.  On the inside of the packet, as it's tunnel mode we
> > should have either IPIP or IPV6, definitely not UDP.
>
> It's triggering in testIPv4UDPEncapRecvTunnel() in xfrm_test.py.
> Specifically, it's the self.ReceivePacketOn(netid, input_pkt) a dozen
> lines higher.
>
> The packet we end up writing into the tap fd is
> 02 00 00 00 C8 01 02 00 00 00 C8 00 08 00
> 45 00 00 44 00 01 00 00 40 11 98 96 08 08 08 08 0A 00 C8 02
> 11 94 BF 12 00 30 1C D0
> 00 00 12 34 00 00 00 01
> 45 00 00 20 00 01 00 00 40 11 98 BA 08 08 08 08 0A 00 C8 02
> 01 BB 7D 7B 00 0C 9B 7A
> 01 02 02 11
>
> You can decode this with https://hpd.gasmi.net/ or https://packetor.com/
>
> You can decode the inner packet (this is null esp crypto) by passing in
> 00 00 00 00 00 00 00 00 00 00 00 00 08 00
> 45 00 00 20 00 01 00 00 40 11 98 BA 08 08 08 08 0A 00 C8 02
> 01 BB 7D 7B 00 0C 9B 7A
> 01 02 02 11
> instead.
>
> Note that the protocol the kernel's printk I added prints is the
> *outer* encap UDP protocol, not the inner UDP.
> ie. you can change the scapy.UDP to scapy.TCP in the 'inner_pkt =' assignment,
> and the warning still triggers.  The resulting packet is:
> 02 00 00 00 FA 01 02 00 00 00 FA 00 08 00
> 45 00 00 50 00 01 00 00 40 11 66 8A 08 08 08 08 0A 00 FA 02
> 11 94 A7 EB 00 3C 33 E0
> 00 00 12 34 00 00 00 01
> 45 00 00 2C 00 01 00 00 40 06 66 B9 08 08 08 08 0A 00 FA 02
> 01 BB 7D 7B 00 00 00 00 00 00 00 00 50 02 20 00 F9 82 00 00
> 01 02 02 11
>
> ie. the inner packet is IPv4/TCP:
> 00 00 00 00 00 00 00 00 00 00 00 00 08 00
> 45 00 00 2C 00 01 00 00 40 06 66 B9 08 08 08 08 0A 00 FA 02
> 01 BB 7D 7B 00 00 00 00 00 00 00 00 50 02 20 00 F9 82 00 00
> 01 02 02 11

It looks like the problem is that final '11', and thus the fix is in
the python test itself:

https://android-review.googlesource.com/c/kernel/tests/+/2647762

-      data += xfrm_base.GetEspTrailer(len(data), IPPROTO_UDP)
+      data += xfrm_base.GetEspTrailer(len(data), {4: IPPROTO_IPIP, 6:
IPPROTO_IPV6}[version])

I guess it's OK that this WARN_ON is remotely triggerable?