[Pkg-openssl-devel] Bug#534892: Debian OpenSSL Bug # 534892

[Russell Coker]

On Tue, 17 May 2011, Scott Schaefer <saschaefer at neurodiverse.org> wrote:
> I am a bit confused...  I am certainly no Helgrind expert [indeed, I had 
> never heard of it until I first read your report), and I will concede 
> that it may know more about C than I do.  However, this certainly 
> appears to me to be a false positive.
> 
> The variable err_fns is declared as:
> static const ERR_FNS *err_fns = NULL;
> 
> Your subject line states "err_fns_check() has a race if a pointer 
> assignment is not atomic".  Except, because the assignment is inside of 
> CRYPTO_w_lock(),CRYPTO_w_unlock(), no race condition exists (assuming 
> these two functions are implemented correctly).

If that function was the only one using the function pointer in question then 
that analysis would be correct.

const ERR_FNS *ERR_get_implementation(void)
        {
        err_fns_check();
        return err_fns;
        }

However it's expected that some other functions such as the above which rely 
on it.  Imagine an architecture which has 64bit pointers but only 32bit 
atomicity for memory writes.  If one thread writes a value to err_fns and gets 
interrupted before completing the operation then another thread could return 
from the first line of err_fns_check() and allow ERR_get_implementation() to 
return data from a half-written memory location.

I could be wrong in this analysis, it would be good if someone who knows more 
about Valgrind than I do could check this out.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/