GHSA-4m85-f9qh-q3jv: Out-of-bounds Read via the TLS 1.3 Certificate extensions_length in NetX Secure
GHSA ID |
|
|---|---|
CVE ID |
CVE‑2026‑92843 |
Severity |
High |
CVSS score |
7.5 ( |
CWE |
|
Published |
2026‑10‑02 |
Last updated |
2026‑10‑02 |
Description
Summary
A missing bounds check in the TLS 1.3 Certificate-message parser of NetX Secure lets a malicious TLS 1.3 server trigger an unsigned-integer underflow and a subsequent heap out-of-bounds read in any peer that processes a remote Certificate message. It is reachable pre-authentication, during the normal handshake, before certificate verification completes.
Details
_nx_secure_tls_process_remote_certificate reads the two-byte per-certificate extensions_length straight off the wire and acts on it without any of the three checks that would bound it:
#if (NX_SECURE_TLS_TLS_1_3_ENABLED)
if(tls_session->nx_secure_tls_1_3)
{
extensions_length = (UINT)((packet_buffer[length] << 8)
+ packet_buffer[length + 1]); /* wire value, unchecked */
length += 2;
length += extensions_length; /* cursor advanced by the unchecked value */
total_length -= (2 + extensions_length); /* UINT underflow */
}
#endif
Nothing establishes that the two-byte field itself fits in message_length, that extensions_length fits in the remaining total_length before the subtraction, or that the extensions lie inside the message before the cursor moves past them. When the declared length exceeds what is left, the subtraction wraps the unsigned total_length to near UINT_MAX.
The certificate-list loop is governed by total_length, so it re-enters, and the per-certificate length fetch then reads three bytes from a cursor that has been advanced far past the end of the message. Those bytes become cert_length and flow onward into _nx_secure_x509_certificate_parse.
The TLS 1.2 sibling path bounds cert_length against total_length. No equivalent guard was ever written for extensions_length.
Impact
Pre-authentication. A TLS 1.3 client processes the server’s Certificate message during the normal handshake, so any network position able to deliver a TLS 1.3 server response — a rogue server, an on-path attacker, a rogue access point — can trigger it. No client credentials are required.
Confirmed: a heap out-of-bounds read of up to roughly 64 KiB, at offsets driven by attacker-controlled bytes, whose contents are then fed to the certificate parser. Without a sanitizer the read is silent.
The same underflow also makes the out-of-bounds cert_length available as a copy size on the following iteration, which is a potential out-of-bounds write. That has not been separately confirmed.
Affected configurations
NetX Secure builds with NX_SECURE_TLS_TLS_1_3_ENABLED defined, on both the client and the server side, since a server performing client-certificate authentication reaches the same function.
Every NetX Duo release up to and including 6.5.1.202602.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — 7.5, High.
C:N reflects that the bytes read are consumed by the DER parser and do not leave it; the impact is the fault an out-of-bounds read produces on a target where the session buffer sits near a memory boundary.
Patches
Fixed in NetX Duo 6.5.2.202603. The two-byte extensions length must lie inside the message before it is read; the certificate entry, its extensions length and its extensions must fit in what is left of the certificate list, which is what stops the subtraction wrapping; and the extensions themselves must lie inside the message before the cursor moves past them. A regression test drives a Certificate message whose extensions length exceeds the remaining list. It must be built with TLS 1.3 enabled; in a configuration without it the test compiles out and reports N/A rather than failing.
The three checks overlap deliberately, and that limits what the test can attribute to each one. All three return NX_SECURE_TLS_INCORRECT_MESSAGE_LENGTH, so removing any single check leaves one of the others to refuse the same input with the same status and the test still passes; removing all three makes it fail. The fix is therefore proven as a whole rather than check by check. Separating them would need a memory sanitizer, since the over-read they prevent lands inside a valid buffer in a test harness.