We are running stress-test with different types of nat-ted traffic and a high number of interfaces (tunnels). Packets coming from tunnels are routed via an interface with nat enabled (nat44 endpoint-dependent mode). Tunnels themselves don't have NAT enabled.

VPP crashes in nat44_ed_in2out_slow_path_node_fn_inline, in a call to vlib_increment_simple_counter.

Our research shows that it was caused by counter corruption; eventually a pointer was clobbered in a counter pointers vector, faulting on the next access.

Counter corruption happens due to out of bounds access to counter vectors. In in2out nodes, packets's source sw_if_index is used to locate the appropriate counter. But there's no mechanism in place to ensure that a counter vector is large enough. Only for interfaces where NAT was enabled explicitly does NAT code ensure that counter vectors are at least as big as the interface index.