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: Sat, 1 Jul 2023 14:27:07 +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 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

> Are you able to reduce this to a set of "ip xfrm" commands that I
> can use to reproduce this?