[openssl-dev] [openssl.org #3891] [PATCH] Fix undefined behavior executed through OpenSSL tests

2015-06-02 Thread Pascal Cuoq via RT
The attached archive contains a collection of patches for undefined behaviors that happen while the tests in directory tests/ are executed, with a recent (as of June 2015) OpenSSL git version. Each undefined behavior really happens for at least one execution, the execution of the test. In other

[openssl-dev] [openssl.org #3950] Standard mem* functions called with length 0 and invalid pointer arguments

2015-07-22 Thread Pascal Cuoq via RT
Recently, GCC began to assume for optimization purposes that p and q are non-null pointers when memcpy(p, q, n); is invoked. This means that the if is eliminated completely when compiling the following sequence of instructions: memcpy(p, q, n); if (!p) printf(good\n); And this causes a

[openssl-dev] [openssl.org #4105] null pointer dereference in BN_lshift when coming from dsa_builtin_paramgen

2015-10-22 Thread Pascal Cuoq via RT
BN_POOL_get() can return NULL when OPENSSL_malloc() fails: https://github.com/openssl/openssl/blob/984d6c6052169bcae8010de33f7796e455536d61/crypto/bn/bn_ctx.c#L365-L366 This causes BN_CTX_get() to return NULL:

[openssl-dev] [openssl.org #4107] [PATCH] null pointer dereference: bn_wexpand return code not checked in bn_g2fm.c

2015-10-26 Thread Pascal Cuoq via RT
The function bn_wexpand() can fail. Most of the invocations in bn_g2fm.c are guarded, but three of them aren't, causing a null pointer dereference when bn_wexpand() fails: https://github.com/openssl/openssl/blob/3f6c7691870d1cd2ad0e0c83638cef3f35a0b548/crypto/bn/bn_gf2m.c#L700 If the calls to

[openssl-dev] [openssl.org #4100] Overlapping memcpy arguments in bn_add.c

2015-10-19 Thread Pascal Cuoq via RT
Hello, this is a follow-up to #3891 (https://mta.openssl.org/pipermail/openssl-dev/2015-June/001667.html ). Kurt Roeckx has committed many fixes to the bugs aggregated in that report. Since, we have been replaying the tests in a recent OpenSSL development version, posterior to these commits,

Re: [openssl-dev] [openssl.org #3891] [PATCH] Fix undefined behavior executed through OpenSSL tests

2015-10-08 Thread Pascal Cuoq via RT
Hello Kurt, thanks for looking into these ! On 07 Oct 2015, at 22:17, Kurt Roeckx via RT wrote: > > So some of the patches got applied, but I have some comments about > the remaining: > - ssl_locl.h.patch: I don't see a struct timeval > crypto/x509v3/v3_scts.c. Does this

[openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

2015-10-14 Thread Pascal Cuoq via RT
As of 2015-10-14, the function PACKET_buf_init in ssl/packet_locl.h reads: static inline int PACKET_buf_init(PACKET *pkt, unsigned char *buf, size_t len) { /* Sanity check for negative values. */ if (buf + len < buf) return 0; pkt->curr = buf; pkt->remaining = len;

[openssl-dev] [openssl.org #4151] [PATCH] Function pop_info in crypto/mem_dbg.c returns a dangling pointer

2015-11-22 Thread Pascal Cuoq via RT
In crypto/mem_dbg.c, the type of static function pop_info() is to return an APP_INFO*. This pointer can be a dangling pointer, as can be seen in the following link as long as one assumes that line 382 is reachable (it is).

[openssl-dev] [openssl.org #4155] In function int_thread_del_item, when hash == int_thread_hash, one is passed to free and the other is used in a comparison

2015-11-24 Thread Pascal Cuoq via RT
This issue is similar in nature to 4151 (http://www.mail-archive.com/openssl-dev@openssl.org/msg40950.html ): it is about a dangling pointer being used, but not used for dereferencing, so it's not a memory error. The dangling pointer is used in a comparison. The function int_thread_del_item