Data race in aes_icm_openssl_alloc

[ukreator]

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.

[ukreator]

Same applies to hmac.ref_count instance defined as global object at hmac_ossl.c:284

[jfigus]

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.

[jfigus]

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.

[jfigus]

This is resolved by c8e9afe in the 2_0_0_dev branch.