Repository navigation
Conversation
Dev10-sys
changed the title
Dev10-sys
force-pushed
the
fix/remote-cert-allocate-uninitialized
branch
from
October 22, 2026 06:30
75963ef to
ee43925
Compare
…e-threadx#473) The documented API contract for nx_secure_tls_remote_certificate_allocate states that caller passes an uninitialized NX_SECURE_X509_CERT structure instance. However, nx_secure_tls_remote_certificate_allocate only assigned the raw buffer pointers and user allocation flag without clearing the certificate structure first. In addition, _nx_secure_x509_certificate_parse did not clear optional fields (extensions data and unique identifiers) when parsing certificates where those blocks are absent, such as X.509 v1 or v2 certificates or reused structures. When an uninitialized or non-zeroed certificate was allocated, nx_secure_x509_extensions_data and nx_secure_x509_extensions_data_length retained uninitialized memory. During certificate verification of self-signed certificates or issuer chains, _nx_secure_x509_key_usage_extension_parse called _nx_secure_x509_extension_find, which attempted to parse ASN.1 TLV blocks from the stale pointer in _nx_secure_x509_asn1_tlv_block_parse, triggering a BusFault/segmentation fault. This fix zeroes the certificate structure in _nx_secure_tls_remote_certificate_allocate before populating fields, explicitly initializes optional extension and identifier fields to NULL and zero in _nx_secure_x509_certificate_parse, and guards _nx_secure_x509_extension_find against NULL or zero-length extension data. A test case in nx_secure_x509_parse_test verifies clean handling for certificates without extensions and non-zeroed initial memory. Signed-off-by: Dev10-sys <kalpanagola9897@gmail.com>
Dev10-sys
force-pushed
the
fix/remote-cert-allocate-uninitialized
branch
from
October 22, 2026 19:16
ee43925 to
d1d1e68
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #473.
Passing an uninitialized certificate to nx_secure_tls_remote_certificate_allocate leaves garbage in the struct because it was never zeroed out. If the server sends an X.509 v1 certificate or one without extensions, the parser doesn't touch the extension fields, so the KeyUsage check tries to read a bad pointer and crashes.
This PR zeroes the certificate struct when allocated, resets optional extension fields in _nx_secure_x509_certificate_parse, and adds a null check in _nx_secure_x509_extension_find to prevent the crash. Tested locally with an uninitialized struct and an X.509 v1 cert.