RFC 5280 7.2:
> When comparing DNS names for equality, conforming implementations
> MUST perform a case-insensitive exact match on the entire DNS name.
> When evaluating name constraints, conforming implementations MUST
> perform a case-insensitive exact match on a label-by-label basis.
Domain name comparison during name constraints processing
was case-sensitive. For excluded name constraints, this could lead to
incorrectly accepting domain names that should've been rejected.
The code for comparing domain names and domain name parts of emails
has been modified to perform case-insensitive comparison instead.
Reported-by: Oleh Konko <security@1seal.org> Reported-by: Joshua Rogers of AISLE Research Team <joshua@joshua.hu> Fixes: #1223 Fixes: #1803 Fixes: #1852 Fixes: CVE-2026-3833 Fixes: GNUTLS-SA-2026-04-29-5
CVSS: 7.4 High CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N Signed-off-by: Alexander Sosedkin <asosedkin@redhat.com>
A server looking up PSK username with a NUL-character in it
was wrongfully matching username truncated at a NUL-character.
Fix the check to compare up to the full username length.
Reported-by: Joshua Rogers of AISLE Research Team <joshua@joshua.hu> Fixes: #1850 Fixes: CVE-2026-42010 Fixes: GNUTLS-SA-2026-04-29-4
CVSS: 7.1 High CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N Signed-off-by: Alexander Sosedkin <asosedkin@redhat.com>
buffers: simplify and tighten parse_handshake_header checks
* frag_size > data_size is now rejected even when length == 0
* length == 0 && frag_size > 0 is now rejected even when start_offset == 0
* start_offset > length is now rejected even when frag_size == 0
Signed-off-by: Alexander Sosedkin <asosedkin@redhat.com>
buffers: switch from end_offset over to frag_length
Instead of maintaining an inclusive [start_offset, end_offset] range
when reassembling DTLS handshake,
track start_offset and a relative frag_length instead.
You'd think it'd be a no-op, but it fixes:
* 0-length fragments triggering completion if message was 1 byte long
* a remotely triggerable underflow and an ensuing heap overrun
Reported-by: Joshua Rogers of AISLE Research Team <joshua@joshua.hu> Fixes: #1811 Fixes: CVE-2026-33845 Fixes: GNUTLS-SA-2026-04-29-3
CVSS: 7.5 High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Signed-off-by: Alexander Sosedkin <asosedkin@redhat.com>
buffers: fix handshake_compare when sequence numbers match
The comparator function used for ordering DTLS packets
by sequence numbers did not follow qsort comparator contracts
in case of packets with duplicate sequence numbers,
which could lead to unstable ordering or undefined behaviour.
Returning 0 in such cases makes the sorting stable.
Reported-by: Joshua Rogers of AISLE Research Team <joshua@joshua.hu> Fixes: #1848 Fixes: CVE-2026-42009 Fixes: GNUTLS-SA-2026-04-29-2
CVSS: 7.5 High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Signed-off-by: Joshua Rogers <joshua@joshua.hu>
lib/buffers: ensure packets have differing sequence numbers
There should normally be no packets with same sequence number and
differing handshake type, unless an adversary crafts them.
Discarding them allows to get rid of packets
with duplicate sequence ID in the buffer,
relieving us from the question of how to sort them later.
Reported-by: Joshua Rogers of AISLE Research Team <joshua@joshua.hu> Fixes: #1848 Fixes: CVE-2026-42009 Fixes: GNUTLS-SA-2026-04-29-2
CVSS: 7.5 High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Signed-off-by: Alexander Sosedkin <asosedkin@redhat.com>
DTLS handshake fragment reassembly previously matched incoming fragments
by handshake type only, without checking the sequence number.
This allowed fragments from different handshake messages
to be merged into the same reassembly buffer.
Now sequence number is accounted for during reassembly,
ensuring fragments are only merged when they belong
to the same handshake message.
Reported-by: Zou Dikai Fixes: #1839 Signed-off-by: Alexander Sosedkin <asosedkin@redhat.com>
Previously, gnutls didn't check that DTLS fragments claimed
a consistent message_length value.
Additionally, a crucial array size check was missing,
enabling an attacker to cause a heap overwrite.
The updated version rejects fragments with mismatching length
and adds a missing boundary check.
Reported-by: Haruto Kimura (Stella) Reported-by: Oscar Reparaz Reported-by: Zou Dikai Fixes: #1816 Fixes: #1838 Fixes: #1839 Fixes: CVE-2026-33846 Fixes: GNUTLS-SA-2026-04-29-1
CVSS: 7.4 High CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H
CVSS: 7.5 High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Signed-off-by: Alexander Sosedkin <asosedkin@redhat.com>
tests: execise client cert selection for RSA-PSS-RSAE algorithms
This adds a test case for 8366cd25ff81ddf27a7a5d885f64a3fdcc0c5125, by
extending send-client-cert test with only RSA-PSS-* signature
algorithms are indicated by the server.
hpke: rework public key serialization logic with existing facilities
Instead of manually serializing or deserializing KEM public keys, use
_gnutls_ecc_ansi_x962_{import,export} for NIST curves and copy
raw_pub from gnutls_pk_params_st for Edwards curves.
hpke: stop exposing testing functions from public API
This removes gnutls_hpke_set_seq, which was unused, and renames
gnutls_hpke_get_seq and gnutls_hpke_set_ikme to be clear that they are
testing functions.
This moves responsibility of initializing gnutls_pubkey_t or
gnutls_privkey_t to the caller of the function, to match the existing
convention in gnutls_privkey_generate*.
Add the signature_algorithms_cert to the list of allowed algorithms if
present, and fallback to the signature_algorithms otherwise.
This better fit [RFC8446 section 4.2.3][1]:
> If no "signature_algorithms_cert" extension is present, then the
> "signature_algorithms" extension also applies to signatures appearing
> in certificates.
This fix TLS 1.3 handshake with Java after [JDK-8349583][2].
lib/pkcs11.c: fix dangling pointer in pkcs11_read_pubkey
Fixes a dangling pointer affecting CKK_EC_EDWARD. if _gnutls_pubkey_parse_ecc_eddsa_params
or _gnutls_ecc_curve_get_params fail, the cleanup section will be executed freeing tmpX
and leaving the datum in pobj dangling.
There was a duplicate cleanup logic at the exit from
namename_constraints_init: one done manually and the other with
name_constraints_deinit. Remove the former as it's redundant.
nettle: support deriving ML-DSA public key from expanded secret key
RFC 9881 defines 3 private key formats for ML-DSA: "seed",
"expandedKey" and both. When it is "expandedKey", a non-trivial
conversion is required to derive a public key, which is now
implemented in leancrypto through lc_dilithium_pk_from_sk. This patch
modifies the pk_fixup backend function to use it to derive a public
key when importing a private key.
projects / thirdparty / gnutls.git / log
