Yes, because "unsigned long" on _LP64 is not 32bits. What is the undefined 
behavior you are trying to fix?

christos

> On Feb 15, 2020, at 7:03 PM, nisarg joshi <njnis...@gmail.com> wrote:
> 
> Hi community,
> 
> 
> 
> While trying to fix UBSan Undefined behavior reports for md4_dgst.c and 
> rmd_dgst.c files which reported issues for the overflow of signed ints etc, I 
> came across a possible out of sync tree of openssl crypto implementations.
> 
> 
> 
> The UBSan report required usage of unsigned int(or long) for MD32_REG_T type 
> and upon checking the upstream openssl/openssl, it seemed to be using the 
> correct data type that would not throw that particular error. Upon tracing 
> the changes in NetBSD openssl code, I found that there was a commit that made 
> changes to the openssl version imported from upstream in 2009. The commits 
> are:
> 
> 1.) Original codebase ==> 
> https://github.com/NetBSD/src/commit/df8082221a1522cb9f9711f39f81796132552e1d 
> <https://github.com/NetBSD/src/commit/df8082221a1522cb9f9711f39f81796132552e1d>
> 2.) Changes made ==> 
> https://github.com/NetBSD/src/commit/309c6b7ae7a7de3f477f9f707d08a4fc12f01b62 
> <https://github.com/NetBSD/src/commit/309c6b7ae7a7de3f477f9f707d08a4fc12f01b62>
> 
> The 2nd commit listed above made changes to the original codebase in such a 
> way that it changed MD32_REG_T to uint32_t and diverged from the upstream. 
> But later MD32_REG_T has been changed to int or long and has become out of 
> sync with the upstream implementation. These changes not only affect the 
> files mentioned earlier but also affect a lot of the files.
> 
> 
> 
> I would request someone to look into the matter and try to sync the 
> implementation and our local modifications to the upstream.
> 
> 
> 
> Thank You
> 
> Nisarg S. Joshi
> 
> 
> <sanitizer.log>

Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to