From: Michael Tremer <git@ipfire.org>
To: ipfire-scm@lists.ipfire.org
Subject: [git.ipfire.org] IPFire 2.x development tree branch, master, updated. 3d971965256c3bd9d6c233675b6b20fc5e51f810
Date: Tue, 27 Aug 2024 09:49:42 +0000 [thread overview]
Message-ID: <4WtN7B3wT7z2xSd@people01.haj.ipfire.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 3899 bytes --]
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "IPFire 2.x development tree".
The branch, master has been updated
via 3d971965256c3bd9d6c233675b6b20fc5e51f810 (commit)
from 8e6bb176b126579f970452ee54effe3e84422e6b (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 3d971965256c3bd9d6c233675b6b20fc5e51f810
Author: Adolf Belka <adolf.belka(a)ipfire.org>
Date: Mon Aug 26 14:24:19 2024 +0200
openssl: Update to version 3.3.1
- Update from 3.3.0 to 3.3.1
- Update of rootfile not required
- This version has 2 CVE fixes both of which are classified as Low Severity so looks like
they can wait for CU189
- Changelog
3.3.1
* Fixed potential use after free after SSL_free_buffers() is called.
The SSL_free_buffers function is used to free the internal OpenSSL
buffer used when processing an incoming record from the network.
The call is only expected to succeed if the buffer is not currently
in use. However, two scenarios have been identified where the buffer
is freed even when still in use.
The first scenario occurs where a record header has been received
from the network and processed by OpenSSL, but the full record body
has not yet arrived. In this case calling SSL_free_buffers will succeed
even though a record has only been partially processed and the buffer
is still in use.
The second scenario occurs where a full record containing application
data has been received and processed by OpenSSL but the application has
only read part of this data. Again a call to SSL_free_buffers will
succeed even though the buffer is still in use.
([CVE-2024-4741])
* Fixed an issue where checking excessively long DSA keys or parameters may
be very slow.
Applications that use the functions EVP_PKEY_param_check() or
EVP_PKEY_public_check() to check a DSA public key or DSA parameters may
experience long delays. Where the key or parameters that are being checked
have been obtained from an untrusted source this may lead to a Denial of
Service.
To resolve this issue DSA keys larger than OPENSSL_DSA_MAX_MODULUS_BITS
will now fail the check immediately with a DSA_R_MODULUS_TOO_LARGE error
reason.
([CVE-2024-4603])
* Improved EC/DSA nonce generation routines to avoid bias and timing
side channel leaks.
Signed-off-by: Adolf Belka <adolf.belka(a)ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer(a)ipfire.org>
-----------------------------------------------------------------------
Summary of changes:
lfs/openssl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Difference in files:
diff --git a/lfs/openssl b/lfs/openssl
index 00b19b41a..d6333f7a4 100644
--- a/lfs/openssl
+++ b/lfs/openssl
@@ -24,7 +24,7 @@
include Config
-VER = 3.3.0
+VER = 3.3.1
THISAPP = openssl-$(VER)
DL_FILE = $(THISAPP).tar.gz
@@ -72,7 +72,7 @@ objects = $(DL_FILE)
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_BLAKE2 = c68efaf8aca87961f396e305acc767b56d651b9adf4fd2c9d9b5a3266e35da4b856c6ed34be47d656c782aade975f20317a6759913b33d29d7eb088e638fa501
+$(DL_FILE)_BLAKE2 = b09bbe94f49c33015fbcee5f578a20c0da33c289791bf33292170d5d3de44ea2e22144ee11067947aef2733e979c0fded875a4ec92d81468285837053447e68e
install : $(TARGET)
hooks/post-receive
--
IPFire 2.x development tree
reply other threads:[~2024-08-27 9:49 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4WtN7B3wT7z2xSd@people01.haj.ipfire.org \
--to=git@ipfire.org \
--cc=ipfire-scm@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox