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]

Message-ID: <CANP3RGcfGGF0mPthDsct1sySFkHeL4jUmq-MFDFxjk6P5qBC1w@mail.gmail.com>
Date: Sat, 1 Jul 2023 14:59:31 +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

> That's a good point.
>
> We should audit all the WARN_ONs in net/xfrm and get rid of the
> ones that can be triggered by a remote peer.

While I'm looking at this code...  I noticed the comment:

     if mode == xfrm.XFRM_MODE_TRANSPORT:
       # Due to a bug in the IPv6 UDP encap code, there must be at least 32
       # bytes after the ESP header or the packet will be dropped.
       # 8 (UDP header) + 18 (payload) + 2 (ESP trailer) = 28, dropped
       # 8 (UDP header) + 19 (payload) + 4 (ESP trailer) = 32, received
       # There is a similar bug in IPv4 encap, but the minimum is only 12 bytes,
       # which is much less likely to occur. This doesn't affect tunnel mode
       # because IP headers are always at least 20 bytes long.
       data = 19 * b"a"
       datalen = len(data)
       data += xfrm_base.GetEspTrailer(len(data), IPPROTO_UDP)

and indeed reducing the 19 to 18 results in the test failing.
(I'm guessing 'encap' in the comment really should be 'decap'...)

I guess this means short IPv6/ESP transport/UDP fail?

I'll dig a little deeper later...