Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
---|---|---|---|---|---|---|
debian-targets.patch | debian-targets | Debian OpenSSL Team <pkg-openssl-devel@lists.alioth.debian.org> | no | 2017-11-05 | ||
man-section.patch | man-section | Debian OpenSSL Team <pkg-openssl-devel@lists.alioth.debian.org> | no | 2017-11-05 | ||
no-symbolic.patch | no-symbolic | Debian OpenSSL Team <pkg-openssl-devel@lists.alioth.debian.org> | no | 2017-11-05 | ||
pic.patch | pic | Debian OpenSSL Team <pkg-openssl-devel@lists.alioth.debian.org> | no | 2017-11-05 | ||
c_rehash-compat.patch | [PATCH] also create old hash for compatibility | Ludwig Nussel <ludwig.nussel@suse.de> | no | 2010-04-21 | ||
Set-systemwide-default-settings-for-libssl-users.patch | Set systemwide default settings for libssl users This config change enforeces a TLS1.2 protocol version as minimum. It can be overwritten by the system administrator. It also changes the default security level from 1 to 2, moving from the 80 bit security level to the 112 bit security level. |
Sebastian Andrzej Siewior <sebastian@breakpoint.cc> | no | 2018-03-20 | ||
c_rehash-Do-not-use-shell-to-invoke-openssl.patch | c_rehash: Do not use shell to invoke openssl Except on VMS where it is safe. This fixes CVE-2022-1292. |
Tomas Mraz <tomas@openssl.org> | no | 2022-04-26 | ||
Fix-file-operations-in-c_rehash.patch | Fix file operations in c_rehash. CVE-2022-2068 [bigeasy: ported from the 3.0 branch with the compat patch] |
Daniel Fiala <daniel@openssl.org> | no | 2022-05-29 | ||
Update-expired-SCT-certificates.patch | Update expired SCT certificates (Merged from https://github.com/openssl/openssl/pull/18446) |
Tomas Mraz <tomas@openssl.org> | no | 2022-06-01 | ||
ct_test.c-Update-the-epoch-time.patch | ct_test.c: Update the epoch time (Merged from https://github.com/openssl/openssl/pull/18446) |
Tomas Mraz <tomas@openssl.org> | no | 2022-06-01 | ||
Update-further-expiring-certificates-that-affect-tests.patch | Update further expiring certificates that affect tests Namely the smime certificates used in test_cms will expire soon and affect tests. Fixes #15179 (Merged from https://github.com/openssl/openssl/pull/18481) |
Tomas Mraz <tomas@openssl.org> | no | 2022-06-02 | ||
Avoid-dangling-ptrs-in-header-and-data-params-for-PEM_rea.patch | Avoid dangling ptrs in header and data params for PEM_read_bio_ex In the event of a failure in PEM_read_bio_ex() we free the buffers we allocated for the header and data buffers. However we were not clearing the ptrs stored in *header and *data. Since, on success, the caller is responsible for freeing these ptrs this can potentially lead to a double free if the caller frees them even on failure. Thanks to Dawei Wang for reporting this issue. Based on a proposed patch by Kurt Roeckx. CVE-2022-4450 |
Matt Caswell <matt@openssl.org> | no | 2022-12-13 | ||
Add-a-test-for-CVE-2022-4450.patch | Add a test for CVE-2022-4450 Call PEM_read_bio_ex() and expect a failure. There should be no dangling ptrs and therefore there should be no double free if we free the ptrs on error. |
Matt Caswell <matt@openssl.org> | no | 2022-12-13 | ||
CVE-2023-0286-Fix-GENERAL_NAME_cmp-for-x400Address-1.1.1.patch | CVE-2023-0286: Fix GENERAL_NAME_cmp for x400Address (1.1.1) | Hugo Landau <hlandau@openssl.org> | no | 2023-01-17 | ||
Fix-a-UAF-resulting-from-a-bug-in-BIO_new_NDEF.patch | Fix a UAF resulting from a bug in BIO_new_NDEF If the aux->asn1_cb() call fails in BIO_new_NDEF then the "out" BIO will be part of an invalid BIO chain. This causes a "use after free" when the BIO is eventually freed. Based on an original patch by Viktor Dukhovni and an idea from Theo Buehler. Thanks to Octavio Galland for reporting this issue. |
Matt Caswell <matt@openssl.org> | no | 2022-12-14 | ||
Check-CMS-failure-during-BIO-setup-with-stream-is-handled.patch | Check CMS failure during BIO setup with -stream is handled correctly Test for the issue fixed in the previous commit |
Matt Caswell <matt@openssl.org> | no | 2022-12-14 | ||
Fix-Timing-Oracle-in-RSA-decryption.patch | Fix 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. Patch written by Dmitry Belyavsky and Hubert Kario CVE-2022-4304 |
Matt Caswell <matt@openssl.org> | no | 2023-01-20 | ||
Fix-AES-OCB-encrypt-decrypt-for-x86-AES-NI.patch | Fix AES OCB encrypt/decrypt for x86 AES-NI aesni_ocb_encrypt and aesni_ocb_decrypt operate by having a fast-path that performs operations on 6 16-byte blocks concurrently (the "grandloop") and then proceeds to handle the "short" tail (which can be anywhere from 0 to 5 blocks) that remain. As part of initialization, the assembly initializes $len to the true length, less 96 bytes and converts it to a pointer so that the $inp can be compared to it. Each iteration of "grandloop" checks to see if there's a full 96-byte chunk to process, and if so, continues. Once this has been exhausted, it falls through to "short", which handles the remaining zero to five blocks. Unfortunately, the jump at the end of "grandloop" had a fencepost error, doing a `jb` ("jump below") rather than `jbe` (jump below or equal). This should be `jbe`, as $inp is pointing to the *end* of the chunk currently being handled. If $inp == $len, that means that there's a whole 96-byte chunk waiting to be handled. If $inp > $len, then there's 5 or fewer 16-byte blocks left to be handled, and the fall-through is intended. The net effect of `jb` instead of `jbe` is that the last 16-byte block of the last 96-byte chunk was completely omitted. The contents of `out` in this position were never written to. Additionally, since those bytes were never processed, the authentication tag generated is also incorrect. The same fencepost error, and identical logic, exists in both aesni_ocb_encrypt and aesni_ocb_decrypt. This addresses CVE-2022-2097. |
Alex Chernyakhovsky <achernya@google.com> | no | 2022-06-16 | ||
AES-OCB-test-vectors.patch | AES OCB test vectors Add test vectors for AES OCB for x86 AES-NI multiple of 96 byte issue. |
Alex Chernyakhovsky <achernya@google.com> | no | 2022-06-16 | ||
x509-excessive-resource-use-verifying-policy-constraints.patch | x509: excessive resource use verifying policy constraints A security vulnerability has been identified in all supported versions of OpenSSL related to the verification of X.509 certificate chains that include policy constraints. Attackers may be able to exploit this vulnerability by creating a malicious certificate chain that triggers exponential use of computational resources, leading to a denial-of-service (DoS) attack on affected systems. Fixes CVE-2023-0464 (Merged from https://github.com/openssl/openssl/pull/20569) |
Pauli <pauli@openssl.org> | no | 2023-03-08 | ||
Ensure-that-EXFLAG_INVALID_POLICY-is-checked-even-in-leaf.patch | Ensure that EXFLAG_INVALID_POLICY is checked even in leaf certs Even though we check the leaf cert to confirm it is valid, we later ignored the invalid flag and did not notice that the leaf cert was bad. (Merged from https://github.com/openssl/openssl/pull/20588) |
Matt Caswell <matt@openssl.org> | no | 2023-03-07 | ||
Generate-some-certificates-with-the-certificatePolicies-e.patch | Generate some certificates with the certificatePolicies extension (Merged from https://github.com/openssl/openssl/pull/20588) |
Matt Caswell <matt@openssl.org> | no | 2023-03-07 | ||
Add-a-Certificate-Policies-Test.patch | Add a Certificate Policies Test Test that a valid certificate policy is accepted and that an invalid certificate policy is rejected. Specifically we are checking that a leaf certificate with an invalid policy is detected. (Merged from https://github.com/openssl/openssl/pull/20588) |
Matt Caswell <matt@openssl.org> | no | 2023-03-07 | ||
Fix-documentation-of-X509_VERIFY_PARAM_add0_policy.patch | Fix documentation of X509_VERIFY_PARAM_add0_policy() The function was incorrectly documented as enabling policy checking. (Merged from https://github.com/openssl/openssl/pull/20564) |
Tomas Mraz <tomas@openssl.org> | no | 2023-03-21 | ||
Revert-Fix-Timing-Oracle-in-RSA-decryption.patch | Revert "Fix Timing Oracle in RSA decryption" This reverts commit ce888cab5b576f53bfe6aebe374efdba5e74e519. |
Sebastian Andrzej Siewior <sebastian@breakpoint.cc> | no | 2023-05-26 | ||
Alternative-fix-for-CVE-2022-4304.patch | Alternative fix for CVE-2022-4304 This is about a timing leak in the topmost limb of the internal result of RSA_private_decrypt, before the padding check. There are in fact at least three bugs together that caused the timing leak: First and probably most important is the fact that the blinding did not use the constant time code path at all when the RSA object was used for a private decrypt, due to the fact that the Montgomery context rsa->_method_mod_n was not set up early enough in rsa_ossl_private_decrypt, when BN_BLINDING_create_param needed it, and that was persisted as blinding->m_ctx, although the RSA object creates the Montgomery context just a bit later. Then the infamous bn_correct_top was used on the secret value right after the blinding was removed. And finally the function BN_bn2binpad did not use the constant-time code path since the BN_FLG_CONSTTIME was not set on the secret value. In order to address the first problem, this patch makes sure that the rsa->_method_mod_n is initialized right before the blinding context. And to fix the second problem, we add a new utility function bn_correct_top_consttime, a const-time variant of bn_correct_top. Together with the fact, that BN_bn2binpad is already constant time if the flag BN_FLG_CONSTTIME is set, this should eliminate the timing oracle completely. In addition the no-asm variant may also have branches that depend on secret values, because the last invocation of bn_sub_words in bn_from_montgomery_word had branches when the function is compiled by certain gcc compiler versions, due to the clumsy coding style. So additionally this patch stream-lined the no-asm C-code in order to avoid branches where possible and improve the resulting code quality. (Merged from https://github.com/openssl/openssl/pull/20284) |
Bernd Edlinger <bernd.edlinger@hotmail.de> | no | 2023-02-13 | ||
Re-add-BN_F_OSSL_BN_RSA_DO_UNBLIND-which-was-incorrectly-.patch | Re-add BN_F_OSSL_BN_RSA_DO_UNBLIND which was incorrectly removed (Merged from https://github.com/openssl/openssl/pull/20784) |
Tomas Mraz <tomas@openssl.org> | no | 2023-04-20 | ||
Restrict-the-size-of-OBJECT-IDENTIFIERs-that-OBJ_obj2txt-.patch | Restrict the size of OBJECT IDENTIFIERs that OBJ_obj2txt will translate 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. To mitigate this, a restriction on the size that OBJ_obj2txt() will translate to canonical numeric text form is added, based on RFC 2578 (STD 58), which says this: > 3.5. OBJECT IDENTIFIER values > > An OBJECT IDENTIFIER value is an ordered list of non-negative numbers. > For the SMIv2, each number in the list is referred to as a sub-identifier, > there are at most 128 sub-identifiers in a value, and each sub-identifier > has a maximum value of 2^32-1 (4294967295 decimal). Fixes otc/security#96 Fixes CVE-2023-2650 |
Richard Levitte <levitte@openssl.org> | no | 2023-05-12 |