The linux-riscv64-openwrt target inherits linux-generic64, which sets no
asm_arch, so OpenSSL builds only its C code on riscv64. Inherit
linux64-riscv64 instead. That adds the riscv64 assembly for AES, GHASH,
ChaCha20 and SHA-2, which uses the Zb*, Zk* and vector crypto extensions
only when the CPU reports them at runtime.
libcrypto.so.3 grows by 24 KiB, and is 2.3 KiB smaller after xz.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25581
Signed-off-by: Robert Marko <robimarko@gmail.com>
libopenssl3 differs between builds depending on the environment of the
build host, e.g. in the images of the Turris Omnia:
-compiler: arm-openwrt-linux-muslgnueabi-gcc -fPIC -pthread -Os ...
+compiler: arm-openwrt-linux-muslgnueabi-gcc -fPIC -pthread -Wa,--noexecstack -Os ...
- GNU_STACK ... RWE 0x10
+ GNU_STACK ... RW 0x10
Configure probes whether the assembler supports --noexecstack by running
$CROSS_COMPILE$CC, with CC taken from the environment. A host which sets
CC to select its compiler, e.g. CC=gcc-13, makes it run
arm-openwrt-linux-muslgnueabi-gcc-13, which does not exist, so the flag
is silently dropped and libcrypto ends up with an executable stack.
Pass CC=gcc to Configure, so that it always probes the cross compiler.
With CC=gcc-13 in the environment, the configuration now gets
-Wa,--noexecstack like a build without CC set.
Link: https://github.com/openwrt/openwrt/pull/25719
Signed-off-by: Paul Spooren <mail@aparcar.org>
RISC-V is becoming more popular, and it's beneficial to have OpenSSL
optimized for speed on riscv64 architectures by default. And many
algorithms in OpenSSL currently lack assembly optimizations for riscv64,
so optimizing for speed for riscv64 will bring significant performance
improvements for C implementations. For example, the performance of
ChaCha20 improves dramatically with this change, from 63603.67k to
129428.12k on Bananapi BPI-RV2 with rva22u64 profile.
All existing boards that use riscv64 that support boot from SDCard or at
least 128M NAND flash, so the slight increase in binary size is
acceptable. And I have tested this change to build with even rva22u64
profile, the libssl.so.3 only increases from 972K to 1.1M, which is
acceptable for most use cases.
Signed-off-by: Yangyu Chen <cyy@cyyself.name>
Link: https://github.com/openwrt/openwrt/pull/21070
Signed-off-by: Robert Marko <robimarko@gmail.com>
Is a security patch release. The most severe CVE fixed
in this release is High.
This release incorporates the following bug fixes and mitigations:
* Fixed DTLS retransmissions of handshake messages from a stale buffer offset.
([CVE-2026-84782])
* Fixed excessive memory allocation in relative CRLDP processing.
([CVE-2026-35189])
* Fixed QUIC unvalidated amplification credit may be over-accounted.
([CVE-2026-35191])
* Fixed potential CPU DoS via O(n^2) fragment reassembly in QUIC.
([CVE-2026-42772])
* Fixed a timing side-channel in scalar multiplication for mon-NIST EC curves.
([CVE-2026-54872])
* Fixed QUIC `STREAM` fragment metadata DoS.
([CVE-2026-54873])
* Fixed non-constant-time SM2 scalar multiplication on ARM64 and RISC-V.
([CVE-2026-54875])
* Fixed out-of-bounds access after `SSL_set_SSL_CTX()` during a handshake.
([CVE-2026-72897])
* Fixed QUIC connection-level flow control was not enforced for streams.
([CVE-2026-75804])
* Fixed a NULL pointer dereference in CMP client revocation response handling.
([CVE-2026-75805])
* Fixed an unauthenticated and undersized DTLS 1.2 AEAD record causing DoS.
([CVE-2026-75806])
* Fixed a timing side-channel in SM2 signature generation.
([CVE-2026-77696])
* Fixed an unbounded `RETIRE_CONNECTION_ID` backlog in QUIC stack
implementation.
([CVE-2026-84784])
* Fixed a bug where `EVP_DecryptFinal()` incorrectly reported a stale success
on AES-SIV authentication failure.
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25557
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The open-coded architecture list pulls libatomic onto every ARM target
although ARMv6K and ARMv7 inline 64-bit atomics. ATOMIC64_DEPENDS
covers exactly the targets whose compiler emits libatomic calls.
OpenSSL's linux-armv4 and mips configurations link libatomic
regardless, so link with --as-needed to drop it where libcrypto
imports nothing from it.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
OpenSSL 3.5.8 fixes zero-length message handling for AES-GCM-SIV
upstream with commit bdeb0cd994d9 ("Check the tag on EVP_Cipher()
finalize: Poly1305 and OCB AEADs", CVE-2026-75803, backport of
5741d29a5f35): aes_gcm_siv_finish() now generates the tag when the
finalization is the first empty-message operation.
That makes the cipher_aes_gcm_siv.c hunk of our local patch redundant,
and worse than redundant. By substituting the address of an empty
object for the NULL input pointer it keeps routing the terminal
EVP_Cipher(ctx, out, NULL, 0) call to aes_gcm_siv_encrypt()/
aes_gcm_siv_decrypt() instead of aes_gcm_siv_finish(), so the tag
supplied by the caller is never compared and a forged tag is accepted.
That is the hole the upstream commit closes.
Measured against a locally built 3.5.8; the EVP_Cipher() return value
is a byte count, so 0 means the tag was accepted and -1 means it was
rejected:
decrypt empty msg EVP_Cipher(out, NULL, 0)
genuine forged genuine forged
3.5.8 vanilla ok rejected 0 -1
3.5.8 + patch 010 ok rejected 0 0 <- bad
3.5.8 + this commit ok rejected 0 -1
AES-SIV has no equivalent fix in 3.5.8 or in openssl master, and
without the second hunk a zero-length message cannot be encrypted at
all, so keep that hunk and rename the patch to match what is left.
Fixes: 2bc7978323 ("openssl: fix AES-GCM-SIV and AES-SIV with zero-length messages")
Assisted-by: Claude:claude-opus-5
Link: https://github.com/openwrt/openwrt/pull/24944
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This release incorporates the following bug fixes and mitigations:
Fixed incorrect failure handling in RSA KEM RSASVE encapsulation.
(CVE-2026-31790)
Fixed loss of key agreement group tuple structure when the DEFAULT keyword
is used in the server-side configuration of the key-agreement group list.
(CVE-2026-2673)
Fixed potential use-after-free in DANE client code.
(CVE-2026-28387)
Fixed NULL pointer dereference when processing a delta CRL.
(CVE-2026-28388)
Fixed possible NULL dereference when processing CMS KeyAgreeRecipientInfo.
(CVE-2026-28389)
Fixed possible NULL dereference when processing CMS
KeyTransportRecipientInfo.
(CVE-2026-28390)
Fixed heap buffer overflow in hexadecimal conversion.
(CVE-2026-31789)
No need refresh patches
Signed-off-by: Jack Sun <sunjiazheng321521@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22847
Signed-off-by: Robert Marko <robimarko@gmail.com>
This commit add option to enable kTLS support, improving
performance by offloading TLS encryption and decryption to
kernel space.
- Reduced CPU usage by minimizing data copying between user space
and kernel space.
- Enables the use of the sendfile() system call with encrypted
sockets for zero-copy data transmission.
- Leverages hardware-accelerated NIC that support TLS offloading.
Signed-off-by: Tan Zien <nabsdh9@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21306
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Fix the cipher implementation to avoid treating empty input as finalizer.
This issue is fixed in the openssl 3.6 branch, but the fix approach from
that branch is not suitable for 3.5, since the code is completely different.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This mainly improve the CFLAGS handling on compilation of OpenSSL.
The CFLAGS are currently passed 2 times generating compilation warning
due to -fhonour-copts passed 2 times.
This can be improved by passing the CFLAGS as env to the OpenSSL
Configure tool.
For consistency we do the same for CPPFLAGS and LDFLAGS.
This permits to drop redundant flags in the Compile phase and from the
.conf file.
Link: https://github.com/openwrt/openwrt/pull/20665
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
release is Moderate.
This release incorporates the following bug fixes and mitigations:
Fix Out-of-bounds read & write in RFC 3211 KEK Unwrap.
(CVE-2025-9230)
Fix Timing side-channel in SM2 algorithm on 64 bit ARM.
(CVE-2025-9231)
Fix Out-of-bounds read in HTTP client no_proxy handling.
(CVE-2025-9232)
Reverted the synthesised OPENSSL_VERSION_NUMBER change for the release
builds, as it broke some exiting applications that relied on the previous
3.x semantics, as documented in OpenSSL_version(3).
Build system: x86/64
Build-tested: x86/64-glibc
Run-tested: x86/64-glibc
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/20275
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Removed upstreamed patch: 0001-Don-t-keep-the-store-open-in-by_store_ctrl_ex.patch
Release notes:
This is a bug fix release.
This release incorporates the following bug fixes and mitigations:
Added FIPS 140-3 PCT on DH key generation.
Fixed the synthesised OPENSSL_VERSION_NUMBER.
Build system: x86/64
Build-tested: x86/64-glibc
Run-tested: x86/64-glibc
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/20133
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
OpenSSL 3.5.2 is a bug fix release:
This release incorporates the following bug fixes and mitigations:
Miscellaneous minor bug fixes.
The FIPS provider now performs a PCT on key import for RSA, EC and ECX.
This is mandated by FIPS 140-3 IG 10.3.A additional comment 1.
Build system: x86/64
Build-tested: x86/64-glibc
Run-tested: x86/64-glibc (Intel N150 based box)
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/19725
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Automatically rebased: 100-Configure-afalg-support.patch
Changes between 3.5.0 and 3.5.1:
Fix x509 application adds trusted use instead of rejected use.
Issue summary: Use of -addreject option with the openssl x509 application
adds a trusted use instead of a rejected use for a certificate.
Impact summary: If a user intends to make a trusted certificate rejected
for a particular use it will be instead marked as trusted for that use.
(CVE-2025-4575)
Aligned the behaviour of TLS and DTLS in the event of a no_renegotiation
alert being received. Older versions of OpenSSL failed with DTLS if a
no_renegotiation alert was received. All versions of OpenSSL do this for TLS.
From 3.2 a bug was exposed that meant that DTLS ignored no_rengotiation.
We have now restored the original behaviour and brought DTLS back into line
with TLS.
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/19283
Signed-off-by: Robert Marko <robimarko@gmail.com>
Changes between 3.0.15 and 3.0.16 [11 Feb 2025]
CVE-2024-13176[1] - Fixed timing side-channel in ECDSA signature
computation.
There is a timing signal of around 300 nanoseconds when the top word of
the inverted ECDSA nonce value is zero. This can happen with significant
probability only for some of the supported elliptic curves. In
particular the NIST P-521 curve is affected. To be able to measure this
leak, the attacker process must either be located in the same physical
computer or must have a very fast network connection with low latency.
CVE-2024-9143[2] - Fixed possible OOB memory access with invalid
low-level GF(2^m) elliptic curve parameters.
Use of the low-level GF(2^m) elliptic curve APIs with untrusted explicit
values for the field polynomial can lead to out-of-bounds memory reads
or writes. Applications working with "exotic" explicit binary (GF(2^m))
curve parameters, that make it possible to represent invalid field
polynomials with a zero constant term, via the above or similar APIs,
may terminate abruptly as a result of reading or writing outside of
array bounds. Remote code execution cannot easily be ruled out.
1. https://www.openssl.org/news/vulnerabilities.html#CVE-2024-13176
2. https://www.openssl.org/news/vulnerabilities.html#CVE-2024-9143
Build system: x86/64
Build-tested: bcm27xx/bcm2712
Run-tested: bcm27xx/bcm2712
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/17947
Signed-off-by: Robert Marko <robimarko@gmail.com>
OpenSSL 3.0.15 is a security patch release. The most severe CVE fixed in this release is Moderate.
This release incorporates the following bug fixes and mitigations:
* Fixed possible denial of service in X.509 name checks (CVE-2024-6119)
* Fixed possible buffer overread in SSL_select_next_proto() (CVE-2024-5535)
Added github releases url as source mirror
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16332
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Currently, the build option to enable/disable engine support isn't
reflected in the final '/etc/ssl/openssl.cnf' config. It assumes `engines`
is always enabled, producing an error whenever running any
commands in openssl util or programs that explicitly use settings
from '/etc/ssl/openssl.cnf'.
```
➤ openssl version
FATAL: Startup failure (dev note: apps_startup()) for openssl
307D1EA97F000000:error:12800067:lib(37):dlfcn_load:reason(103):crypto/dso/dso_dlfcn.c:118:filename(libengines.so):
Error loading shared library libengines.so: No such file or directory
307D1EA97F000000:error:12800067:lib(37):DSO_load:reason(103):crypto/dso/dso_lib.c:152:
307D1EA97F000000:error:0700006E:lib(14):module_load_dso:reason(110):crypto/conf/conf_mod.c:321:module=engines, path=engines
307D1EA97F000000:error:07000071:lib(14):module_run:reason(113):crypto/conf/conf_mod.c:266:module=engines
```
Build should check for the `CONFIG_OPENSSL_ENGINE` option, and comment out `engines`
if not explicitly enabled.
Example:
```
[openssl_init]
providers = provider_sect
```
After this change, openssl util works correctly.
```
➤ openssl version
OpenSSL 3.0.14 4 Jun 2024 (Library: OpenSSL 3.0.14 4 Jun 2024)
```
Signed-off-by: Sean Khan <datapronix@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/15661
Signed-off-by: Robert Marko <robimarko@gmail.com>
Major changes between OpenSSL 3.0.13 and OpenSSL 3.0.14 [04-Jun-2024]
* Fixed potential use after free after SSL_free_buffers() is called.
[CVE-2024-4741]
* Fixed checking excessively long DSA keys or parameters may be very slow.
[CVE-2024-4603]
* Fixed an issue where some non-default TLS server configurations can cause
unbounded memory growth when processing TLSv1.3 sessions. An attacker may
exploit certain server configurations to trigger unbounded memory growth that
would lead to a Denial of Service. [CVE-2024-2511]
* New atexit configuration switch, which controls whether the OPENSSL_cleanup
is registered when libcrypto is unloaded. This can be used on platforms
where using atexit() from shared libraries causes crashes on exit
Signed-off-by: John Audia <therealgraysky@proton.me>
Build system: x86/64
Build-tested: x86/64/AMD Cezanne
Add "linux64-loongarch64-openwrt" into openssl configurations to enable
building on loongarch64 machines.
Signed-off-by: Weijie Gao <hackpascal@gmail.com>
Major changes between OpenSSL 3.0.12 and OpenSSL 3.0.13 [30 Jan 2024]
* Fixed PKCS12 Decoding crashes
([CVE-2024-0727])
* Fixed Excessive time spent checking invalid RSA public keys
([CVE-2023-6237])
* Fixed POLY1305 MAC implementation corrupting vector registers on PowerPC
CPUs which support PowerISA 2.07
([CVE-2023-6129])
* Fix excessive time spent in DH check / generation with large Q parameter
value ([CVE-2023-5678])
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
Major changes between OpenSSL 3.0.11 and OpenSSL 3.0.12 [24 Oct 2023]
* Mitigate incorrect resize handling for symmetric cipher keys and IVs. (CVE-2023-5363)
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Changes between 3.0.10 and 3.0.11 [19 Sep 2023]
* Fix POLY1305 MAC implementation corrupting XMM registers on Windows. ([CVE-2023-4807])
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
Changes between 3.0.9 and 3.0.10 [1 Aug 2023]
* Fix excessive time spent checking DH q parameter value ([CVE-2023-3817])
* Fix DH_check() excessive time with over sized modulus ([CVE-2023-3446])
* Do not ignore empty associated data entries with AES-SIV ([CVE-2023-2975])
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
openssl sets additional cflags in its configuration script. We need to
make it aware of our custom cflags to avoid adding conflicting cflags.
Fixes: #12866
Signed-off-by: Jitao Lu <dianlujitao@gmail.com>
CVE-2023-2650 fix
Remove upstreamed patches
Major changes between OpenSSL 3.0.8 and OpenSSL 3.0.9 [30 May 2023]
* Mitigate for very slow OBJ_obj2txt() performance with gigantic OBJECT IDENTIFIER sub-identities. (CVE-2023-2650)
* Fixed buffer overread in AES-XTS decryption on ARM 64 bit platforms (CVE-2023-1255)
* Fixed documentation of X509_VERIFY_PARAM_add0_policy() (CVE-2023-0466)
* Fixed handling of invalid certificate policies in leaf certificates (CVE-2023-0465)
* Limited the number of nodes created in a policy tree (CVE-2023-0464)
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
Built-in engine configs are added in libopenssl-conf/install stage
already, postinst/add_engine_config is just duplicating them, and
due to the lack of `config` header it results a broken uci config:
> uci: Parse error (invalid command) at line 3, byte 0
```
config engine 'devcrypto'
option enabled '1'
engine 'devcrypto'
option enabled '1'
option builtin '1'
```
Add `builtin` option in libopenssl-conf/install stage and remove
duplicate engine configuration in postinst/add_engine_config to
fix this issue.
Fixes: 0b70d55a64 ("openssl: make UCI config aware of built-in engines")
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
This applies commit 02ac9c94 to fix this OpenSSL Security Advisory
issued on 20th April 2023[1]:
Input buffer over-read in AES-XTS implementation on 64 bit ARM
(CVE-2023-1255)
==============================================================
Severity: Low
Issue summary: The AES-XTS cipher decryption implementation for 64 bit
ARM platform contains a bug that could cause it to read past the input
buffer, leading to a crash.
Impact summary: Applications that use the AES-XTS algorithm on the 64
bit ARM platform can crash in rare circumstances. The AES-XTS algorithm
is usually used for disk encryption.
The AES-XTS cipher decryption implementation for 64 bit ARM platform
will read past the end of the ciphertext buffer if the ciphertext size
is 4 mod 5 in 16 byte blocks, e.g. 144 bytes or 1024 bytes. If the
memory after the ciphertext buffer is unmapped, this will trigger a
crash which results in a denial of service.
If an attacker can control the size and location of the ciphertext
buffer being decrypted by an application using AES-XTS on 64 bit ARM,
the application is affected. This is fairly unlikely making this issue a
Low severity one.
1. https://www.openssl.org/news/secadv/20230420.txt
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Apply two patches fixing low-severity vulnerabilities related to
certificate policies validation:
- Excessive Resource Usage Verifying X.509 Policy Constraints
(CVE-2023-0464)
Severity: Low
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.
Policy processing is disabled by default but can be enabled by passing
the `-policy' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
- Invalid certificate policies in leaf certificates are silently ignored
(CVE-2023-0465)
Severity: Low
Applications that use a non-default option when verifying certificates
may be vulnerable to an attack from a malicious CA to circumvent
certain checks.
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.
Policy processing is disabled by default but can be enabled by passing
the `-policy' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
Note: OpenSSL also released a fix for low-severity security advisory
CVE-2023-466. It is not included here because the fix only changes the
documentation, which is not built nor included in any OpenWrt package.
Due to the low-severity of these issues, there will be not be an
immediate new release of OpenSSL.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This adapts the engine build infrastructure to allow building providers,
and packages the legacy provider. Providers are the successors of
engines, which have been deprecated.
The legacy provider supplies OpenSSL implementations of algorithms that
have been deemed legacy, including DES, IDEA, MDC2, SEED, and Whirlpool.
Even though these algorithms are implemented in a separate package,
their removal makes the regular library smaller by 3%, so the build
options will remain to allow lean custom builds. Their defaults will
change to 'y' if not bulding for a small flash, so that the regular
legacy package will contain a complete set of algorithms.
The engine build and configuration structure was changed to accomodate
providers, and adapt to the new style of openssl.cnf in version 3.0.
There is not a clean upgrade path for the /etc/ssl/openssl.cnf file,
installed by the openssl-conf package. It is recommended to rename or
remove the old config file when flashing an image with the updated
openssl-conf package, then apply the changes manually.
An old openssl.cnf file will silently work, but new engine or provider
packages will not be enabled. Any remaining engine config files under
/etc/ssl/engines.cnf.d can be removed.
On the build side, the include file used by engine packages was renamed
to openssl-module.mk, so the engine packages in other feeds need to
adapt.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Engines that are built into the main libcrypto OpenSSL library can't be
disabled through UCI. Add a 'builtin' setting to signal that the engine
can't be disabled through UCI, and show a message explaining this in
case buitin=1 and enabled=0.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Building openssl with OPENSSL_SMALL_FOOTPRINT yelds only from 1% to 3%
decrease in size, dropping performance from 2% to 91%, depending on the
target and algorithm.
For example, using AES256-GCM with 1456-bytes operations, X86_64 appears
to be the least affected with 2% performance penalty and 1% reduction in
size; mips drops performance by 13%, size by 3%; Arm drops 29% in
performance, 2% in size.
On aarch64, it slows down ghash so much that I consider it broken
(-91%). SMALL_FOOTPRINT will reduce AES256-GCM performance by 88%, and
size by only 1%. It makes an AES-capable CPU run AES128-GCM at 35% of
the speed of Chacha20-Poly1305:
Block-size=1456 bytes AES256-GCM AES128-GCM ChaCha20-Poly1305
SMALL_FOOTPRINT 62014.44 65063.23 177090.50
regular 504220.08 565630.28 182706.16
OpenSSL 1.1.1 numbers are about the same, so this should have been
noticed a long time ago.
This creates an option to use OPENSSL_SMALL_FOOTPRINT, but it is turned
off by default unless SMALL_FLASH or LOW_MEMORY_FOOTPRINT is used.
Compiling with -O3 instead of -Os, for comparison, will increase size by
about 14-15%, with no measureable effect on AES256-GCM performance, and
about 2% increase in Chacha20-Poly1305 performance on Aarch64.
There are no Arm devices with the small flash feature, so drop the
conditional default. The package is built on phase2, so even if we
include an Arm device with small flash later, a no-asm library would
have to be built from source anyway.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This reduces open coding and allows to easily add a knob to
enable it treewide, where chosen packages can still opt-out via
"no-gc-sections".
Note: libnl, mbedtls and opkg only used the CFLAGS part without the
LDFLAGS counterpart. That doesn't help at all if the goal is to produce
smaller binaries. I consider that an accident, and this fixes it.
Note: there are also packages using only the LDFLAGS part. I didn't
touch those, as gc might have been disabled via CFLAGS intentionally.
Signed-off-by: Andre Heider <a.heider@gmail.com>
Fix the trivial abscence of $() when assigning engine config files to
the main libopenssl-config package even if the corresponding engines
were not built into the main library.
This is mostly cosmetic, since scripts/ipkg-build tests the file's
presence before it is actually included in the package's conffiles.
Fixes: 30b0351039 "openssl: configure engine packages during install"
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
The bump to 3.0.8 inadvertently removed patches that are needed here,
but were not adopted upstream. The most important one changes the
default value of the DIGESTS setting from ALL to NONE. The absence of
this patch causes a sysupgrade failure while the engine is in use with
digests enabled. When this happens, the system fails to boot with a
kernel panic.
Also, explicitly set DIGESTS to NONE in the provided config file, and
change the default ciphers setting to disable ECB, which has been
recommended for a long time and may cause trouble with some apps.
The config file change by itself is not enough because the config file
may be preserved during sysupgrade.
For people affected by this bug:
You can either:
1. remove, the libopenssl-devcrypto package
2. disable the engine in /etc/config/openssl;
3. change /etc/ssl/engines.cnf.d/devcrypto.cnf to set DIGESTS=NONE;
4. update libopenssl-devcrypto to >=3.0.8-3
However, after doing any of the above, **you must reboot the device
before running sysupgrade** to ensure no running application is using
the engine. Running `/etc/init.d/openssl restart` is not enough.
Fixes: 7e7e76afca "openssl: bump to 3.0.8"
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
PowerPC CONFIG_ARCH is defined as powerpc, not ppc. Fix that in the
DEPENDS condition.
Arc needs to be built with libatomic. Change the OpenSSL configuration
file, and add it to the libatomic DEPENDS condition.
Fixes: 7e7e76afca "openssl: bump to 3.0.8"
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Removed upstreamed patch: 010-padlock.patch
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]
Signed-off-by: John Audia <therealgraysky@proton.me>
Byte swapping code incorrectly uses the number of AES rounds to swap expanded
AES key, while swapping only a single dword in a loop, resulting in swapped
key and partially swapped expanded keys, breaking AES encryption and
decryption on VIA Padlock hardware.
This commit correctly sets the number of swapping loops to be done.
Upstream: https://github.com/openssl/openssl/commit/2bcf8e69bd92e33d84c48e7d108d3d46b22f8a6d
Acked-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Signed-off-by: ValdikSS ValdikSS <iam@valdikss.org.ru>
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]
Build system: x86_64
Build-tested: bcm2711/RPi4B
Run-tested: bcm2711/RPi4B
Signed-off-by: John Audia <therealgraysky@proton.me>