GHSA-f95g-xc4w-mrcr: Out-of-bounds read in _nx_secure_x509_asn1_tlv_block_parse()

_nx_secure_x509_asn1_tlv_block_parse reads the one byte ASN.1 tag from the caller’s buffer before checking that the buffer holds at least one byte. When a caller passes a remaining length of zero the guard returns NX_SECURE_X509_ASN1_LENGTH_TOO_LONG as it should, but the read has already happened one byte past the end of the buffer. The function is the primitive underneath all X.509 certificate parsing in NetX Secure, so it runs on certificates supplied by a remote peer during the TLS handshake.

The tag load is the only read in the function placed ahead of its check. The rest is correctly ordered: the multi byte length path is guarded before its read loop, the decoded length is checked against the remaining length, and the second single byte length read follows its own guard.

Reaching it requires a caller that arrives with a remaining length of zero. _nx_secure_x509_certificate_parse passes the caller’s length straight through, and several call sites invoke the parser sequentially without re-checking the remaining length between calls. Where the first call consumes the whole remainder, the second receives a pointer one past the end of the buffer together with a remaining length of zero, which is exactly the triggering condition. The certificate exhaustion loop elsewhere in the same file is wrapped in a positive length test and cannot reach the parser this way; the unguarded sequential call sites are the reachable ones.

The reporter found the condition by fuzzing _nx_secure_tls_process_remote_certificate with a corpus of DER encoded certificates, and reproduced it independently by extracting the function into a harness that models the tail pointer case with an exact size allocation.

A one byte read immediately past the end of the certificate buffer. The byte is interpreted as an ASN.1 tag and can therefore influence which parse error is returned, but it is not returned to the peer and there is no information disclosure path. On the flat memory maps typical of the targets this stack runs on, the read is very unlikely to fault.

The practical consequence is limited. What makes it worth fixing is that it is a genuine out of bounds read on a parsing path a remote peer can reach before authentication.

Any build that parses X.509 certificates, which is every NetX Secure TLS configuration. No option gates the affected function.

Every release up to and including 6.5.1.202602 is affected.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, 5.3, Medium.

Confidentiality is scored at none because the byte never leaves the parser: it selects an error code and is not transmitted. Availability is the only measurable effect, and it is low because a one byte overread on these targets rarely reaches an unmapped page.

Fixed in NetX Duo 6.5.2.202603.

The tag read moves below the length check, so the guard runs first. The returned status is unchanged; only the order of the load and the check differs.

A regression test, nx_secure_x509_asn1_zero_length_test, now covers it. The test could not assert on the returned status, because a zero length returns NX_SECURE_X509_ASN1_LENGTH_TOO_LONG with or without the fix: the guard was always present and only the load sat above it, so the read itself is the whole difference. It instead hands the parser a null buffer with a zero length, which the fixed code never dereferences and the unfixed code does, and it segfaults against the unfixed source. It also covers the shape that reaches this from the wire, a certificate too short to hold a block, for its status alone.

Reported and fixed by @tinic, who discovered the condition by fuzzing the remote certificate parsing entry point and submitted the corrected ordering.

The regression test was produced with AI assistance under human review, in accordance with the Eclipse Foundation’s Generative AI Usage Guidelines.