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...