[issue] conntrack: lack of lock during nat

[ze wang <wangze712@gmail.com>]

Hi Pablo,
         I'm doing CPS testing for conntrack，and I think there may be an issue
in some scenarios. Here is the example：

iptables -t nat -A POSTROUTING -d 10.0.0.5 -p tcp -j SNAT --to 10.0.0.1

pkt from p1: IP(src="10.0.0.2",dst="10.0.0.5")/TCP(sport=5555,dport=8888,seq=100)
pkt from p2: IP(src="10.0.0.3",dst="10.0.0.5")/TCP(sport=5555,dport=8888,seq=100)

        If the number of attempts is large enough, there is a chance that the
conntracks generated by the two packets will conflict, because their tuples
in the reply direction have the same ip and port.
        The reason for this phenomenon may be in the process of executing
nat,there are two small locks in choosing nat tuple(ip and port) and
confirming ct, but there is no lock between them(before confirm and
after choose), which may cause kernel threads choosing the same
reply tuple and confirming them, then go to clash resolve.
        I’m not sure if my thoughts are correct, or there is any other
mechanism in
the kernel to prevent this and I didn't find it. Can this be
considered an issue?

Thank you,
wangze