If no connection could be made, addr_iter will eventually end up being
NULL, and if the user didn't check the returned error value, the
BIO_CONN_S_CONNECT code will be performed again and will crash.
So instead, we add a state BIO_CONN_S_CONNECT_ERROR that we enter into
when we run out of addresses to try. That state will just simply say
"error" back, until the user does something better with the BIO, such
as free it or reset it.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10333)
On systems with undefined AI_ADDRCONFIG and AI_NUMERICHOST:
x86_64-w64-mingw32-gcc -I. -Icrypto/include -Iinclude -m64 -Wall -O3 -fno-ident ...
crypto/bio/b_addr.c: In function 'BIO_lookup_ex':
crypto/bio/b_addr.c:699:7: warning: label 'retry' defined but not used [-Wunused-label]
retry:
^~~~~
Regression from: 3f91ede9ae
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/9856)
(cherry picked from commit be66a15cc1a4c3cc68fa854ceea321ca57f96304)
Make the include guards consistent by renaming them systematically according
to the naming conventions below
The public header files (in the 'include/openssl' directory) are not changed
in 1.1.1, because it is a stable release.
For the private header files files, the guard names try to match the path
specified in the include directives, with all letters converted to upper case
and '/' and '.' replaced by '_'. An extra 'OSSL_' is added as prefix.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)
Apart from public and internal header files, there is a third type called
local header files, which are located next to source files in the source
directory. Currently, they have different suffixes like
'*_lcl.h', '*_local.h', or '*_int.h'
This commit changes the different suffixes to '*_local.h' uniformly.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)
Currently, there are two different directories which contain internal
header files of libcrypto which are meant to be shared internally:
While header files in 'include/internal' are intended to be shared
between libcrypto and libssl, the files in 'crypto/include/internal'
are intended to be shared inside libcrypto only.
To make things complicated, the include search path is set up in such
a way that the directive #include "internal/file.h" could refer to
a file in either of these two directoroes. This makes it necessary
in some cases to add a '_int.h' suffix to some files to resolve this
ambiguity:
#include "internal/file.h" # located in 'include/internal'
#include "internal/file_int.h" # located in 'crypto/include/internal'
This commit moves the private crypto headers from
'crypto/include/internal' to 'include/crypto'
As a result, the include directives become unambiguous
#include "internal/file.h" # located in 'include/internal'
#include "crypto/file.h" # located in 'include/crypto'
hence the superfluous '_int.h' suffixes can be stripped.
The files 'store_int.h' and 'store.h' need to be treated specially;
they are joined into a single file.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)
Found by OSS-Fuzz
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
GH: #9959
(cherry picked from commit a6105ef40d65b35818f2b8ae8ca9e57ca6956d1d)
We should not retry on EAI_MEMORY as that error is most probably
fatal and not depending on AI_ADDRCONFIG hint.
Also report the error from the first call if the second call fails
as that one would be most probably the more interesting one.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9535)
(cherry picked from commit 91cb81d40a)
Do not try to discern the error return value on
getaddrinfo() failure but when retrying set the AI_NUMERICHOST
to avoid DNS lookups.
Fixes: #9053
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9535)
(cherry picked from commit 7f616a00e9)
CLA: trivial
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/9295)
This include guard inside an object file comes as a surprise and
serves no purpose anymore. It seems like this object file was
included by crypto/threads/mttest.c at some time, but the include
directive was removed in commit bb8abd6.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/9365)
The BIO_FLAGS_NONCLEAR_RST flag behavior was not properly documented
and it also caused the length to be incorrectly set after the reset
operation.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9179)
(cherry picked from commit 8b7b32921e)
When compiling with --strict-warnings using gcc 7.4.0 the compiler
complains that a case falls through, even though there is an explicit
comment stating this. Moving the comment outside of the conditional
compilation section resolves this.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9131)
(cherry picked from commit a2e520447e)
The lookup for ::1 with getaddrinfo() might return error even if
the ::1 would work if AI_ADDRCONFIG flag is used.
Fixes: #9053
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9108)
(cherry picked from commit 3f91ede9ae)
This prevents failure of openssl s_server socket binding to wildcard
address on hosts with disabled IPv6.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8550)
(cherry picked from commit b8472b4e67)
Cygwin binaries should not enforce text mode these days, just
use text mode if the underlying mount point requests it
Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8248)
(cherry picked from commit 9b57e4a1ef)
If you use a BIO and set up your own buffer that is not freed, the
memory bio will leak the BIO_BUF_MEM object it allocates.
The trouble is that the BIO_BUF_MEM is allocated and kept around,
but it is not freed if BIO_NOCLOSE is set.
The freeing of BIO_BUF_MEM was fairly confusing, simplify things
so mem_buf_free only frees the memory buffer and free the BIO_BUF_MEM
in mem_free(), where it should be done.
Alse add a test for a leak in the memory bio
Setting a memory buffer caused a leak.
Signed-off-by: Corey Minyard <minyard@acm.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8051)
(cherry picked from commit c6048af23c)
The BIO callback handling incorrectly wrote over the return code passed
to the callback, meaning that an incorrect result was (eventually) returned
to the caller.
Fixes#7343
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7344)
(cherry picked from commit d97ce8d9a0)
BIO_s_log() is declared for everyone, so should return NULL when not
actually implemented. Also, it had explicit platform limitations in
util/mkdef.pl that didn't correspond to what was actually in code.
While at it, a few other hard coded things that have lost their
relevance were removed.
include/openssl/ocsp.h had a few duplicate declarations.
Reviewed-by: Paul Yang <yang.yang@baishancloud.com>
(Merged from https://github.com/openssl/openssl/pull/7331)
(cherry picked from commit 7e09c5eaa5)
- fix to use secure URL in generated Windows resources
- fix a potentially uninitialized variable
- fix an unused variable warning
CLA: trivial
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7189)
When the input length is zero, just return zero early. Otherwise,
there's a small chance that memory allocation is engaged, fails and
returns -1, which is a bit confusing when nothing should be written.
Fixes#4782#4827
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/6175)
get_last_sys_error() already exists, so there's no need for yet
another macro that fulfills the same purpose.
Fixes#4120
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6088)
The warning reads "[cast] may cause misaligned access". Even though
this can be application-supplied pointer, misaligned access shouldn't
happen, because structure type is "encoded" into data itself, and
application would customarily pass correctly aligned pointer. But
there is no harm in resolving the warning...
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5894)
This removes some code because we cannot trace the original contributor
to get their agreement for the licence change (original commit e03ddfae).
After this change there will be numerous failures in the test cases until
someone rewrites the missing code.
All *_free functions should accept a NULL parameter. After this change
the following *_free functions will fail if a NULL parameter is passed:
BIO_ACCEPT_free()
BIO_CONNECT_free()
BN_BLINDING_free()
BN_CTX_free()
BN_MONT_CTX_free()
BN_RECP_CTX_free()
BUF_MEM_free()
COMP_CTX_free()
ERR_STATE_free()
TXT_DB_free()
X509_STORE_free()
ssl3_free()
ssl_cert_free()
SSL_SESSION_free()
SSL_free()
[skip ci]
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/5757)
Don't pass a pointer to uninitialized processed value
for BIO_CB_READ and BIO_CB_WRITE
Check the correct cmd code in BIO_callback_ctrl
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5516)
Add -bind option to s_client application to allow specification of
local address for connection.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5272)
Without that, output comes one character per line. It's the same
issue as has been observed before, this happens when using write()
on a record oriented stream (possibly unbuffered too).
This also uncovered a bug in BIO_f_linebuffer, where this would cause
an error:
BIO_write(bio, "1\n", 1);
I.e. there's a \n just after the part of the string that we currently
ask to get written.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5352)
when the data block ends with SPACEs or NULs.
The problem is, you can't see if the data ends
with SPACE or NUL or a combination of both.
This can happen for instance with
openssl rsautl -decrypt -hexdump
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5328)
Conceptually, this is a squashed version of:
Revert "Address feedback"
This reverts commit 75551e07bd.
and
Revert "Add CRYPTO_thread_glock_new"
This reverts commit ed6b2c7938.
But there were some intervening commits that made neither revert apply
cleanly, so instead do it all as one shot.
The crypto global locks were an attempt to cope with the awkward
POSIX semantics for pthread_atfork(); its documentation (the "RATIONALE"
section) indicates that the expected usage is to have the prefork handler
lock all "global" locks, and the parent and child handlers release those
locks, to ensure that forking happens with a consistent (lock) state.
However, the set of functions available in the child process is limited
to async-signal-safe functions, and pthread_mutex_unlock() is not on
the list of async-signal-safe functions! The only synchronization
primitives that are async-signal-safe are the semaphore primitives,
which are not really appropriate for general-purpose usage.
However, the state consistency problem that the global locks were
attempting to solve is not actually a serious problem, particularly for
OpenSSL. That is, we can consider four cases of forking application
that might use OpenSSL:
(1) Single-threaded, does not call into OpenSSL in the child (e.g.,
the child calls exec() immediately)
For this class of process, no locking is needed at all, since there is
only ever a single thread of execution and the only reentrancy is due to
signal handlers (which are themselves limited to async-signal-safe
operation and should not be doing much work at all).
(2) Single-threaded, calls into OpenSSL after fork()
The application must ensure that it does not fork() with an unexpected
lock held (that is, one that would get unlocked in the parent but
accidentally remain locked in the child and cause deadlock). Since
OpenSSL does not expose any of its internal locks to the application
and the application is single-threaded, the OpenSSL internal locks
will be unlocked for the fork(), and the state will be consistent.
(OpenSSL will need to reseed its PRNG in the child, but that is
an orthogonal issue.) If the application makes use of locks from
libcrypto, proper handling for those locks is the responsibility of
the application, as for any other locking primitive that is available
for application programming.
(3) Multi-threaded, does not call into OpenSSL after fork()
As for (1), the OpenSSL state is only relevant in the parent, so
no particular fork()-related handling is needed. The internal locks
are relevant, but there is no interaction with the child to consider.
(4) Multi-threaded, calls into OpenSSL after fork()
This is the case where the pthread_atfork() hooks to ensure that all
global locks are in a known state across fork() would come into play,
per the above discussion. However, these "calls into OpenSSL after
fork()" are still subject to the restriction to async-signal-safe
functions. Since OpenSSL uses all sorts of locking and libc functions
that are not on the list of safe functions (e.g., malloc()), this
case is not currently usable and is unlikely to ever be usable,
independently of the locking situation. So, there is no need to
go through contortions to attempt to support this case in the one small
area of locking interaction with fork().
In light of the above analysis (thanks @davidben and @achernya), go
back to the simpler implementation that does not need to distinguish
"library-global" locks or to have complicated atfork handling for locks.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5089)
