Last Modified: Nov 07, 2022
See more info
Known Affected Versions:
12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168
14.0.0, 22.214.171.124, 126.96.36.199
Opened: Feb 21, 2018
SSL SNI mechanism creates a hash containing a mapping between SAN entries in a given profile's certificate and the profile. This hash is owned by the default SNI profile, however is held by the other profiles on the VIP without a reference. If a connection utilizes SNI to use a non-default SNI profile *and* the default SNI profile reinitializes its state for any reason, the prf->sni_certsn_hash can be cleared and freed, leaving the existing connection(s) with profiles that refer to the freed hash. If then the connection attempts a renegotiation that causes the hash to be used, the freed hash can cause a fault should it have been reused in the meantime (i.e. the contents are invalid). The fix: When the default SNI profile is initializing, and SSL handshake is searching SAN/COMMON cert from non-default SNI profile, stop the search and return NULL.
Traffic is disrupted while TMM restarts.
SNI configured with one default SNI profile, one or multiple SNI profiles. The default SNI profile is changed and renegotiation with SNI(with non-default SNI profile) is issued.
There is no workaround at this time.
When the default SNI profile is initializing, and SSL handshake is searching SAN/COMMON cert from non-default SNI profile, stop the search and return NULL.