hi， I found that in the _gcry_mpi_ec_internal_new() function, the parameter E.p passed to _gcry_mpi_ec_p_internal_new() may be a null pointer, resulting in an error in the for(; a->nlimbs && !a->d[a->nlimbs-1]; a->nlimbs--) statement in _gcry_mpi_normalize().
Description
Description
Event Timeline
Comment Actions
I tried to fix the segmentation fault, so I added a null pointer check at the end to protect it.
Comment Actions
If you pass NULL to that function, the calling code is wrong. No need for an explicit check in nomralize - check should be done in the public API (if at all).
Comment Actions
When I look at the stack information, I find that because E->p is not assigned in the function mpi_ec_get_elliptic_curve(), this produces a null pointer，but it didn't get to the branch : if (errc) goto leave;
Comment Actions
Thank you for your report. IIUC, it is called unexpected way, like invalid/wrong KEYPARMS. Possibly, KEYPARMS == NULL, or something like that.
If so, it is mpi_ec_get_elliptic_curve which should return an error correctly, not the next function which tries to use it.
As a bug report, it is more useful, when you show us a particular test case (minimum is better).
This comment was removed by • gniibe.
Comment Actions
Ah, I found that we have very bad example use case in tests/t-mpi-point.c. This should be fixed at first.
Comment Actions
I figured out the situation.
Like the use cases in tests/t-mpi-point.c, libgcrypt allows peculiar use of gcry_mpi_ec_new with partial parameters (not full), so that a part of feature of ECC could be used.
So, it doesn't check all parameters should be filled for ECC.
When partial parameters is used, it's at user's risk to encounter SEGV.
This is the current situation.
Please don't use partial parameters, for your application, if you are serious. It's for development of new curves or very limited use.