diff options
author | Paul Selkirk <paul@psgd.org> | 2017-07-31 23:06:33 -0400 |
---|---|---|
committer | Paul Selkirk <paul@psgd.org> | 2017-07-31 23:06:33 -0400 |
commit | 63636301593c8a3952afae61c1b5f279c27f69ea (patch) | |
tree | b3a72e1a154fd2efb6fa66d53619b58b64920df4 /hash.c | |
parent | 19f92790c2f9fc7f4e019d7b20663453606f210f (diff) |
Unconditionally set the allocated flag when initializing a hash state
structure.
When running multiple concurrent unit tests, I observed multiple failures
in the hmac tests, which I ultimately tracked down to different clients
sharing the same hal_hmac_state struct.
hal_hash_initialize is called twice in hal_hmac_initialize (once to get
the state structure, then again if the supplied key is too long), and is
called in hal_hmac_finalize, to hash the digest with the supplied key. In
these subsequent cases, the caller supplies the state structure, which
hal_hash_initialize zeroes, but it doesn't set the allocated flag. This
marks an in-use struct as available, so it gets reassigned and
reinitialized, and Bad Things Happen for both clients that are trying to
use it.
Diffstat (limited to 'hash.c')
-rw-r--r-- | hash.c | 8 |
1 files changed, 1 insertions, 7 deletions
@@ -443,10 +443,7 @@ hal_error_t hal_hash_initialize(hal_core_t *core, state->descriptor = descriptor; state->driver = driver; state->core = core; - state->flags = flags; - - if (state_buffer == NULL) - state->flags |= STATE_FLAG_STATE_ALLOCATED; + state->flags = flags | STATE_FLAG_STATE_ALLOCATED; *state_ = state; @@ -777,9 +774,6 @@ hal_error_t hal_hmac_initialize(hal_core_t *core, sizeof(state->hash_state))) != HAL_OK) goto fail; - if (state_buffer == NULL) - h->flags |= STATE_FLAG_STATE_ALLOCATED; - /* * If the supplied HMAC key is longer than the hash block length, we * need to hash the supplied HMAC key to get the real HMAC key. |