Looking at how this code works in detail, I believe we currently would only see issues if multiple host processes (with saddr == IPV4_MASQUERADE) are concurrently sending pings to the same destination, using the same identifier value.
Here skipping the NAT means that we can't resolve the identifier re-use, and can't differentiate the ECHO_REPLY packets.

This doesn't feel like a real-world problem, hence not backporting :).

/test

Just to confirm, with this change, we skip some of the logics in the snat_v4/v6_nat_can_skip other than the port range check. The if (target->egress_gateway) part and !target->from_local_endpoint part. Are we sure we also skip them?

That's correct. We care about conditions where snat_v*_nat_can_skip() would still return true. But if we agree that the sport < NAT_MIN_EGRESS condition is not valid for ICMP_ECHO, then the function essentially turns into what's sketched out below - and thus always returns false for ICMP_ECHO. So we don't even need to call it.

static __always_inline bool
snat_v4_nat_can_skip(const struct ipv4_nat_target *target,
		     const struct ipv4_ct_tuple *tuple)
{
	__u16 sport = bpf_ntohs(tuple->sport);

#if defined(ENABLE_EGRESS_GATEWAY_COMMON) && defined(IS_BPF_HOST)
	if (target->egress_gateway)
		return false;
#endif

        if (ICMP_ECHO)
	   return (!target->from_local_endpoint && false);
 
	return (!target->from_local_endpoint && sport < NAT_MIN_EGRESS);
}