Your message dated Mon, 9 Jan 2017 22:26:15 +0100
with message-id <[email protected]>
and subject line Re: Bug#534706: libssl0.9.8: OPENSSL_cleanse() is reported as 
being thread-unsafe by helgrind
has caused the Debian Bug report #534706,
regarding libssl0.9.8: OPENSSL_cleanse() is reported as being thread-unsafe by 
helgrind
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
534706: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534706
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libssl0.9.8
Version: 0.9.8g-15+lenny1
Severity: normal

==28427== Possible data race during read of size 1 at 0x55ef868 by thread #3
==28427==    at 0x52CFC41: OPENSSL_cleanse (mem_clr.c:67)
==28427==    by 0x533647F: EVP_MD_CTX_cleanup (digest.c:322)
==28427==    by 0x53367AF: EVP_DigestFinal (digest.c:221)
==28427==    by 0x40F1C3: CDKIMVerify::GetResults() (dkimverify.cpp:460)
==28427==    by 0x40378A: dkim_verify(int, char const*, int, unsigned char**, 
char***) (dkim-test.cpp:122)
==28427==    by 0x403D06: do_work(void*) (dkim-test.cpp:359)
==28427==    by 0x4C26ABF: mythread_wrapper (hg_intercepts.c:194)
==28427==    by 0x4E2FFC6: start_thread (in /lib/libpthread-2.7.so)
==28427==    by 0x5E8B5AC: clone (in /lib/libc-2.7.so)
==28427==  This conflicts with a previous write of size 1 by thread #2
==28427==    at 0x52CFC80: OPENSSL_cleanse (mem_clr.c:76)
==28427==    by 0x52CFBD4: CRYPTO_realloc_clean (mem.c:361)
==28427==    by 0x5325A97: BUF_MEM_grow_clean (buffer.c:149)
==28427==    by 0x53429E1: asn1_d2i_read_bio (a_d2i_fp.c:227)
==28427==    by 0x5342C40: ASN1_d2i_bio (a_d2i_fp.c:93)
==28427==    by 0x406A94: dk_end (domainkeys.c:1945)
==28427==    by 0x406D22: dk_eom (domainkeys.c:1982)
==28427==    by 0x4034CC: domainkeys_verify(int, char const*, int, unsigned 
char**, char***) (dkim-test.cpp:218)

The above is from running helgrind on my AMD64 system.

cleanse_ctr is a global variable which is both read and written by
OPENSSL_cleanse() without locking.  It probably doesn't matter much as it's
only used as a source of entropy for scrubbing memory prior to freeing it.
Can we flag this variable to be skipped by helgrind checks?

Also it would be good if the source could include a comment with a reference
to the research showing the need for such memory scrubbing.



--- End Message ---
--- Begin Message ---
On 2009-06-26 23:54:54 [+1000], Russell Coker wrote:
> cleanse_ctr is a global variable which is both read and written by
> OPENSSL_cleanse() without locking.  It probably doesn't matter much as it's
> only used as a source of entropy for scrubbing memory prior to freeing it.
> Can we flag this variable to be skipped by helgrind checks?

the code changed (cleanse_ctr is gone) and therefore closing this one.
If this still applies please open a new one.

Sebastian

--- End Message ---

Reply via email to