https://github.com/openssl/openssl/commits/ and pick the appropriate
release branch.
+ Changes between 1.1.1v and 1.1.1w [11 Sep 2023]
+
+ *) Fix POLY1305 MAC implementation corrupting XMM registers on Windows.
+
+ The POLY1305 MAC (message authentication code) implementation in OpenSSL
+ does not save the contents of non-volatile XMM registers on Windows 64
+ platform when calculating the MAC of data larger than 64 bytes. Before
+ returning to the caller all the XMM registers are set to zero rather than
+ restoring their previous content. The vulnerable code is used only on newer
+ x86_64 processors supporting the AVX512-IFMA instructions.
+
+ The consequences of this kind of internal application state corruption can
+ be various - from no consequences, if the calling application does not
+ depend on the contents of non-volatile XMM registers at all, to the worst
+ consequences, where the attacker could get complete control of the
+ application process. However given the contents of the registers are just
+ zeroized so the attacker cannot put arbitrary values inside, the most likely
+ consequence, if any, would be an incorrect result of some application
+ dependent calculations or a crash leading to a denial of service.
+
+ (CVE-2023-4807)
+ [Bernd Edlinger]
+
+
+ Changes between 1.1.1u and 1.1.1v [1 Aug 2023]
+
+ *) Fix excessive time spent checking DH q parameter value.
+
+ The function DH_check() performs various checks on DH parameters. After
+ fixing CVE-2023-3446 it was discovered that a large q parameter value can
+ also trigger an overly long computation during some of these checks.
+ A correct q value, if present, cannot be larger than the modulus p
+ parameter, thus it is unnecessary to perform these checks if q is larger
+ than p.
+
+ If DH_check() is called with such q parameter value,
+ DH_CHECK_INVALID_Q_VALUE return flag is set and the computationally
+ intensive checks are skipped.
+
+ (CVE-2023-3817)
+ [Tomáš Mráz]
+
+ *) Fix DH_check() excessive time with over sized modulus
+
+ The function DH_check() performs various checks on DH parameters. One of
+ those checks confirms that the modulus ("p" parameter) is not too large.
+ Trying to use a very large modulus is slow and OpenSSL will not normally use
+ a modulus which is over 10,000 bits in length.
+
+ However the DH_check() function checks numerous aspects of the key or
+ parameters that have been supplied. Some of those checks use the supplied
+ modulus value even if it has already been found to be too large.
+
+ A new limit has been added to DH_check of 32,768 bits. Supplying a
+ key/parameters with a modulus over this size will simply cause DH_check()
+ to fail.
+ (CVE-2023-3446)
+ [Matt Caswell]
+
+ Changes between 1.1.1t and 1.1.1u [30 May 2023]
+
+ *) Mitigate for the time it takes for `OBJ_obj2txt` to translate gigantic
+ OBJECT IDENTIFIER sub-identifiers to canonical numeric text form.
+
+ OBJ_obj2txt() would translate any size OBJECT IDENTIFIER to canonical
+ numeric text form. For gigantic sub-identifiers, this would take a very
+ long time, the time complexity being O(n^2) where n is the size of that
+ sub-identifier. (CVE-2023-2650)
+
+ To mitigitate this, `OBJ_obj2txt()` will only translate an OBJECT
+ IDENTIFIER to canonical numeric text form if the size of that OBJECT
+ IDENTIFIER is 586 bytes or less, and fail otherwise.
+
+ The basis for this restriction is RFC 2578 (STD 58), section 3.5. OBJECT
+ IDENTIFIER values, which stipulates that OBJECT IDENTIFIERS may have at
+ most 128 sub-identifiers, and that the maximum value that each sub-
+ identifier may have is 2^32-1 (4294967295 decimal).
+
+ For each byte of every sub-identifier, only the 7 lower bits are part of
+ the value, so the maximum amount of bytes that an OBJECT IDENTIFIER with
+ these restrictions may occupy is 32 * 128 / 7, which is approximately 586
+ bytes.
+
+ Ref: https://datatracker.ietf.org/doc/html/rfc2578#section-3.5
+
+ [Richard Levitte]
+
+ *) Reworked the Fix for the Timing Oracle in RSA Decryption (CVE-2022-4304).
+ The previous fix for this timing side channel turned out to cause
+ a severe 2-3x performance regression in the typical use case
+ compared to 1.1.1s. The new fix uses existing constant time
+ code paths, and restores the previous performance level while
+ fully eliminating all existing timing side channels.
+ The fix was developed by Bernd Edlinger with testing support
+ by Hubert Kario.
+ [Bernd Edlinger]
+
+ *) Corrected documentation of X509_VERIFY_PARAM_add0_policy() to mention
+ that it does not enable policy checking. Thanks to
+ David Benjamin for discovering this issue. (CVE-2023-0466)
+ [Tomas Mraz]
+
+ *) Fixed an issue where invalid certificate policies in leaf certificates are
+ silently ignored by OpenSSL and other certificate policy checks are skipped
+ for that certificate. A malicious CA could use this to deliberately assert
+ invalid certificate policies in order to circumvent policy checking on the
+ certificate altogether. (CVE-2023-0465)
+ [Matt Caswell]
+
+ *) Limited the number of nodes created in a policy tree to mitigate
+ against CVE-2023-0464. The default limit is set to 1000 nodes, which
+ should be sufficient for most installations. If required, the limit
+ can be adjusted by setting the OPENSSL_POLICY_TREE_NODES_MAX build
+ time define to a desired maximum number of nodes or zero to allow
+ unlimited growth. (CVE-2023-0464)
+ [Paul Dale]
+
+ Changes between 1.1.1s and 1.1.1t [7 Feb 2023]
+
+ *) Fixed X.400 address type confusion in X.509 GeneralName.
+
+ There is a type confusion vulnerability relating to X.400 address processing
+ inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING
+ but subsequently interpreted by GENERAL_NAME_cmp as an ASN1_TYPE. This
+ vulnerability may allow an attacker who can provide a certificate chain and
+ CRL (neither of which need have a valid signature) to pass arbitrary
+ pointers to a memcmp call, creating a possible read primitive, subject to
+ some constraints. Refer to the advisory for more information. Thanks to
+ David Benjamin for discovering this issue. (CVE-2023-0286)
+
+ This issue has been fixed by changing the public header file definition of
+ GENERAL_NAME so that x400Address reflects the implementation. It was not
+ possible for any existing application to successfully use the existing
+ definition; however, if any application references the x400Address field
+ (e.g. in dead code), note that the type of this field has changed. There is
+ no ABI change.
+ [Hugo Landau]
+
+ *) Fixed Use-after-free following BIO_new_NDEF.
+
+ The public API function BIO_new_NDEF is a helper function used for
+ streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL
+ to support the SMIME, CMS and PKCS7 streaming capabilities, but may also
+ be called directly by end user applications.
+
+ The function receives a BIO from the caller, prepends a new BIO_f_asn1
+ filter BIO onto the front of it to form a BIO chain, and then returns
+ the new head of the BIO chain to the caller. Under certain conditions,
+ for example if a CMS recipient public key is invalid, the new filter BIO
+ is freed and the function returns a NULL result indicating a failure.
+ However, in this case, the BIO chain is not properly cleaned up and the
+ BIO passed by the caller still retains internal pointers to the previously
+ freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO
+ then a use-after-free will occur. This will most likely result in a crash.
+ (CVE-2023-0215)
+ [Viktor Dukhovni, Matt Caswell]
+
+ *) Fixed Double free after calling PEM_read_bio_ex.
+
+ The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and
+ decodes the "name" (e.g. "CERTIFICATE"), any header data and the payload
+ data. If the function succeeds then the "name_out", "header" and "data"
+ arguments are populated with pointers to buffers containing the relevant
+ decoded data. The caller is responsible for freeing those buffers. It is
+ possible to construct a PEM file that results in 0 bytes of payload data.
+ In this case PEM_read_bio_ex() will return a failure code but will populate
+ the header argument with a pointer to a buffer that has already been freed.
+ If the caller also frees this buffer then a double free will occur. This
+ will most likely lead to a crash.
+
+ The functions PEM_read_bio() and PEM_read() are simple wrappers around
+ PEM_read_bio_ex() and therefore these functions are also directly affected.
+
+ These functions are also called indirectly by a number of other OpenSSL
+ functions including PEM_X509_INFO_read_bio_ex() and
+ SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL
+ internal uses of these functions are not vulnerable because the caller does
+ not free the header argument if PEM_read_bio_ex() returns a failure code.
+ (CVE-2022-4450)
+ [Kurt Roeckx, Matt Caswell]
+
+ *) Fixed Timing Oracle in RSA Decryption.
+
+ A timing based side channel exists in the OpenSSL RSA Decryption
+ implementation which could be sufficient to recover a plaintext across
+ a network in a Bleichenbacher style attack. To achieve a successful
+ decryption an attacker would have to be able to send a very large number
+ of trial messages for decryption. The vulnerability affects all RSA padding
+ modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.
+ (CVE-2022-4304)
+ [Dmitry Belyavsky, Hubert Kario]
+
+ Changes between 1.1.1r and 1.1.1s [1 Nov 2022]
+
+ *) Fixed a regression introduced in 1.1.1r version not refreshing the
+ certificate data to be signed before signing the certificate.
+ [Gibeom Gwon]
+
+ Changes between 1.1.1q and 1.1.1r [11 Oct 2022]
+
+ *) Fixed the linux-mips64 Configure target which was missing the
+ SIXTY_FOUR_BIT bn_ops flag. This was causing heap corruption on that
+ platform.
+ [Adam Joseph]
+
+ *) Fixed a strict aliasing problem in bn_nist. Clang-14 optimisation was
+ causing incorrect results in some cases as a result.
+ [Paul Dale]
+
+ *) Fixed SSL_pending() and SSL_has_pending() with DTLS which were failing to
+ report correct results in some cases
+ [Matt Caswell]
+
+ *) Fixed a regression introduced in 1.1.1o for re-signing certificates with
+ different key sizes
+ [Todd Short]
+
+ *) Added the loongarch64 target
+ [Shi Pujin]
+
+ *) Fixed a DRBG seed propagation thread safety issue
+ [Bernd Edlinger]
+
+ *) Fixed a memory leak in tls13_generate_secret
+ [Bernd Edlinger]
+
+ *) Fixed reported performance degradation on aarch64. Restored the
+ implementation prior to commit 2621751 ("aes/asm/aesv8-armx.pl: avoid
+ 32-bit lane assignment in CTR mode") for 64bit targets only, since it is
+ reportedly 2-17% slower and the silicon errata only affects 32bit targets.
+ The new algorithm is still used for 32 bit targets.
+ [Bernd Edlinger]
+
+ *) Added a missing header for memcmp that caused compilation failure on some
+ platforms
+ [Gregor Jasny]
+
+ Changes between 1.1.1p and 1.1.1q [5 Jul 2022]
+
+ *) AES OCB mode for 32-bit x86 platforms using the AES-NI assembly optimised
+ implementation would not encrypt the entirety of the data under some
+ circumstances. This could reveal sixteen bytes of data that was
+ preexisting in the memory that wasn't written. In the special case of
+ "in place" encryption, sixteen bytes of the plaintext would be revealed.
+
+ Since OpenSSL does not support OCB based cipher suites for TLS and DTLS,
+ they are both unaffected.
+ (CVE-2022-2097)
+ [Alex Chernyakhovsky, David Benjamin, Alejandro Sedeño]
+
Changes between 1.1.1o and 1.1.1p [21 Jun 2022]
*) In addition to the c_rehash shell command injection identified in