You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Field ref_count in cipher_type_t struct for aes_icm, aes_icm_192 and aes_icm_256 global instances is incremented in aes_icm_openssl_alloc, e.g. aes_icm_ossl.c:141:
aes_icm.ref_count++;
This causes data race when someone creates srtp contexts in different threads. I know it's pretty harmless, but it's undefined behavior anyway, so better be fixed.
The text was updated successfully, but these errors were encountered:
It looks like the same problem exists in the legacy code (aes_icm.c).
This appears to be benign since the ref_count isn't used anywhere. It
might be best to simply delete the ref_count member from cipher_type_t.
On 02/17/2014 01:33 AM, Dmitry Sobinov wrote:
This issue is for openssl branch.
Field ref_count in cipher_type_t struct for aes_icm, aes_icm_192 and
aes_icm_256 global instances is incremented in aes_icm_openssl_alloc,
e.g. aes_icm_ossl.c:141:
aes_icm.ref_count++;
This causes data race when someone creates srtp contexts in different
threads. I know it's pretty harmless, but it's undefined behavior
anyway, so better be fixed.
—
Reply to this email directly or view it on GitHub #39.
Leaving this issue open for now. We should address this in 2.0. The only place the ref_count appears to be used is in the crypto kernel code that simply displays the current reference count. Downstream projects may be using the ref_count due to opacity issues.
This issue is for openssl branch.
Field ref_count in cipher_type_t struct for aes_icm, aes_icm_192 and aes_icm_256 global instances is incremented in aes_icm_openssl_alloc, e.g. aes_icm_ossl.c:141:
aes_icm.ref_count++;
This causes data race when someone creates srtp contexts in different threads. I know it's pretty harmless, but it's undefined behavior anyway, so better be fixed.
The text was updated successfully, but these errors were encountered: