ASA drop packets unexpectively

We have the following scenario for connection:

A ——– outside inte–ASA–inside inte———B

A has TCP conntion with B, but connection was interrupted sometime during the communicaiton. I did packet capture on both inside and outside interfaces of ASA in order to find out what was going on during this communcation. And I found that some packets on inside interface of ASA has been dropped:
those packets showed up in inside interfaces, but did not present in outside interfaces, instead, ASA reply to B on behave of A. That leads to the issue that A keep sending
retransmission packets but got no reply, when timeout A send Fin packet to close the connection, on the other side B was communicating all the time until got Fin packets from A, in response B send back ACK and FIN packets too, still, this AC &FIN packets was caught by ASA and dropped:

A ———————–ASA———————–B
—–>pktAtoB n———|—–pktAtoB n———–>
——–no traffic——- |<—-pktBtoA n+1———
——–no traffi——– |—->pktAtoB n repeat—>
—–>pketAtoB retrans—|—->pktAto B retrans—>
——-no traffic———|<—-pktBtoA n+1———
——-no traffic———|—->pktAtoB n repeat—-
after 5 retransmission or timeout
—–no traffic———–|<——ACK—————
—–no traffic———–|<——FIN—————-

A closed the connection because got no reply from B, B close the connections too after receiving FIN(supposelly after timeout for half-closing tcp connection)
While ASA still keep this connection in the connection table until idle timeout.

In order to find out the reason why ASA dropped the packet, we may use capture with the following command:
ASA>capture drop type asp-drop all

asp-drop Capture packets dropped with a particular reason

This will capture all the dropped packets by ASA, at most cases if there is a drop-reason “tcp-paws-fail” as example, ASA will print the drop-reason for one packet, other packets that match this connection and dropped for the same reason will be in the outputs with no drop reason until another drop reason appear.

In our case, we have hit the ASA bug ‘ASA drops packet as PAWS failure’, and after consulting Cisco engineer, we got the info that”to know if your version is affected or not, you need to look at the known fixed releases. So, since version 9.1.(7.12) is the first version in the train 9.1.7 that fixed this bug, this mean all other versions before in the same train 9.1.7 are affected with this bug.”