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
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
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
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,
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
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;
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).
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