Skip to content

Conversation

@theStack
Copy link
Contributor

@theStack theStack commented Dec 6, 2025

We currently have five public API functions that take an "array of pointers" as input parameter:

  • secp256k1_ec_pubkey_combine (ins: array of pointers to public keys to add)
  • secp256k1_ec_pubkey_sort (pubkeys: array of pointers to public keys to sort)
  • secp256k1_musig_pubkey_agg (pubkeys: array of pointers to public keys to aggregate)
  • secp256k1_musig_nonce_agg (pubnonces: array of pointers to public nonces to aggregate)
  • secp256k1_musig_partial_sig_agg (partial_sigs: array of pointers to partial signatures to aggregate)

Out of these, only _ec_pubkey_combine verifies that the individual pointer elements in the array are non-NULL each:

secp256k1/src/secp256k1.c

Lines 774 to 775 in e7f7083

for (i = 0; i < n; i++) {
ARG_CHECK(pubnonces[i] != NULL);

This PR adds corresponding ARG_CHECKS for the other API functions as well, in order to avoid running into potential UB due to NULL pointer dereference. It seems to me that the tiny run-time overhead is worth it doing this for consistency and to help users in case the arrays are set up incorrectly (I'm thinking e.g. of language binding writers where getting this right might be a bit more involved).

Looking into this was motivated by a review of furszy (thanks!), who pointed out that the non-NULL checks are missing in at least one API function in the silentpayments module PR as well. Happy to add some CHECK_ILLEGAL tests if there is conceptual support for this PR.

@furszy
Copy link
Member

furszy commented Dec 6, 2025

Cool, the review paid off so fast :). Would be good to add test coverage for it.

Copy link
Contributor

@real-or-random real-or-random left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK

@theStack
Copy link
Contributor Author

theStack commented Dec 9, 2025

Added CHECK_ILLEGAL tests to ensure NULL pointers in "array of pointer" arguments for the mentioned five functions are detected. They are placed right after (or at least as close to) successful executions with n_{pubkeys,pubnonces,sigs} >= 2 each and test with a single NULL pointer at each position.

Copy link
Contributor

@real-or-random real-or-random left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK 8bcda18

@kevkevinpal
Copy link

utACK 8bcda18

Copy link
Member

@furszy furszy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we have to perform these three checks in many places:

  1. Pointer to array is not null.
  2. Provided number of elements in the array is greater than zero.
  3. No element inside the array is null

What about introducing a new macro?

/* Check array of pointers is non-NULL, non-empty, and has no NULL entries */
#define ARG_CHECK_ARRAY(arr, n) do {                                    \
        size_t _pos;                                                    \
        ARG_CHECK((arr) != NULL);                                       \
        ARG_CHECK((n) > 0);                                             \
        for (_pos = 0; _pos < (n); _pos++) {                            \
            ARG_CHECK((arr)[_pos] != NULL);                             \
        }                                                               \
} while(0)

Could also introduce one for when the array can be empty too.

@john-moffett
Copy link
Contributor

utACK 8bcda18

I like the macro idea, but I'd make the non-empty part explicit, like ARG_CHECK_ARRAY_NONEMPTY or something.

Copy link

@w0xlt w0xlt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.
ACK 8bcda18

@real-or-random
Copy link
Contributor

real-or-random commented Dec 10, 2025

What about introducing a new macro?

Concept ~0: It's more DRY, and it will make it harder for people to forget one of the checks, e.g., that the members are non-NULL, in new code. On the other hand, I believe the code will be more difficult to read with a macro. Having the three checks explicitly is not super verbose, and noone will need to look up or remember the definition of the macro. (Note that we'd use the macro only in a handful of functions, so people may not recall the definiton.)

@real-or-random real-or-random merged commit be5e4f0 into bitcoin-core:master Dec 10, 2025
122 checks passed
@theStack theStack deleted the ARG_CHECK-array-of-pointers-elements-non-NULL branch December 10, 2025 10:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants