Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory leak in XECKEY computeECDHSecret #387

Open
jasonkatonica opened this issue Dec 9, 2024 · 0 comments · May be fixed by #393
Open

Memory leak in XECKEY computeECDHSecret #387

jasonkatonica opened this issue Dec 9, 2024 · 0 comments · May be fixed by #393

Comments

@jasonkatonica
Copy link
Member

By placing the test BaseTestXDH classes variation testXDH_X25519 into a tight loop with many iterations it can be observed that the following context is leaking as per a leak report:

STACK OF 1894953 INSTANCES OF 'ROOT LEAK: <malloc in CRYPTO_zalloc>':
4   ???                                   0x16e74be7c 0x7fffffffffffffff + 9223372043002887805
3   libjgskit.dylib                       0x107fb5880 Java_com_ibm_crypto_plus_provider_ock_NativeInterface_XECKEY_1computeECDHSecret + 148
2   libicclib085.dylib                    0x1157e57d8 int_ctx_new + 212
1   libicclib085.dylib                    0x1157cd558 CRYPTO_zalloc + 76
0   libsystem_malloc.dylib                0x19419a840 _malloc_zone_malloc_instrumented_or_legacy + 264 
====
    9466824 (867M) << TOTAL >>
      ----
      34 (3.20K) ROOT LEAK: <malloc in CRYPTO_zalloc 0x505c18f40> [80]
         29 (2.73K) <malloc in CRYPTO_zalloc 0x505c19560> [80]
            27 (2.45K) <malloc in CRYPTO_zalloc 0x505c195b0> [80]
               25 (2.34K) unaligned +27:  --> <malloc in omrmem_allocate_memory 0x117519f20> [96]
                  24 (2.25K) <malloc in omrmem_allocate_memory 0x117477910> [96]
                     23 (2.16K) <malloc in omrmem_allocate_memory 0x10870f4e0> [96]
                        22 (2.06K) <malloc in omrmem_allocate_memory 0x12681d920> [96]
                           21 (1.97K) <malloc in omrmem_allocate_memory 0x10800c450> [96]
                              20 (1.88K) <malloc in omrmem_allocate_memory 0x1171c6a30> [96]
                                 19 (1.78K) <malloc in omrmem_allocate_memory 0x116dc2f10> [96]
                                    18 (1.69K) <malloc in omrmem_allocate_memory 0x116dc1380> [96]
                                       17 (1.59K) <malloc in omrmem_allocate_memory 0x12681dfa0> [96]
                                          16 (1.50K) <malloc in omrmem_allocate_memory 0x116ef06d0> [96]
                                             15 (1.41K) <malloc in omrmem_allocate_memory 0x1171c66d0> [96]
                                                14 (1.31K) <malloc in omrmem_allocate_memory 0x12681d840> [96]
                                                   13 (1.22K) <malloc in omrmem_allocate_memory 0x12760b730> [96]
                                                      12 (1.12K) <malloc in omrmem_allocate_memory 0x10870c3d0> [96]
                                                         11 (1.03K) <malloc in omrmem_allocate_memory 0x115cbee50> [96]
                                                            10 (960 bytes) <malloc in omrmem_allocate_memory 0x116dc1e00> [96]
                                                               9 (864 bytes) <malloc in omrmem_allocate_memory 0x1172bcbb0> [96]
                                                                  8 (768 bytes) <malloc in omrmem_allocate_memory 0x10870dad0> [96]
                                                                     7 (672 bytes) <malloc in omrmem_allocate_memory 0x12681cee0> [96]
                                                                        6 (576 bytes) <malloc in omrmem_allocate_memory 0x1172cda60> [96]
                                                                           5 (480 bytes) <malloc in omrmem_allocate_memory 0x1376dacd0> [96]
                                                                              4 (384 bytes) <malloc in omrmem_allocate_memory 0x117469a70> [96]
                                                                                 3 (288 bytes) <malloc in omrmem_allocate_memory 0x10800b710> [96]
                                                                                    2 (192 bytes) <malloc in omrmem_allocate_memory 0x11644b360> [96]
                                                                                       1 (96 bytes) <malloc in omrmem_allocate_memory 0x1171c60b0> [96]
               1 (32 bytes) <malloc in ecx_key_op 0x505c193e0> [32]
            1 (208 bytes) <pthread_rwlock_t 0x505c19660> [208]
         4 (400 bytes) <malloc in CRYPTO_zalloc 0x505c19310> [80]
            1 (208 bytes) <pthread_rwlock_t 0x505c19490> [208]
            2 (112 bytes) <malloc in CRYPTO_zalloc 0x505c19410> [80]
               1 (32 bytes) <malloc in ecx_key_op 0x505c19460> [32]
      ----
      10 (960 bytes) ROOT LEAK: <malloc in CRYPTO_zalloc 0x1208efc10> [80]
         5 (480 bytes) <malloc in CRYPTO_zalloc 0x1208effe0> [80]
            1 (208 bytes) <pthread_rwlock_t 0x1208f0160> [208]
            3 (192 bytes) <malloc in CRYPTO_zalloc 0x1208f00e0> [80]
               1 (80 bytes) unaligned +27:  --> <malloc in CRYPTO_zalloc 0x124c15260> [80]
               1 (32 bytes) <malloc in ecx_key_op 0x1208f0130> [32]
         4 (400 bytes) <malloc in CRYPTO_zalloc 0x1208f0230> [80]
            1 (208 bytes) <pthread_rwlock_t 0x1208f0330> [208]
            2 (112 bytes) <malloc in CRYPTO_zalloc 0x1208f0280> [80]
               1 (32 bytes) <malloc in ecx_key_op 0x1208f00b0> [32]
      ----
      10 (960 bytes) ROOT LEAK: <malloc in CRYPTO_zalloc 0x120c32a60> [80]
         5 (480 bytes) <malloc in CRYPTO_zalloc 0x120c32e30> [80]
            1 (208 bytes) <pthread_rwlock_t 0x120c32fb0> [208]
            3 (192 bytes) <malloc in CRYPTO_zalloc 0x120c32f30> [80]
               1 (80 bytes) unaligned +27:  --> <malloc in CRYPTO_zalloc 0x116129f90> [80]
               1 (32 bytes) <malloc in ecx_key_op 0x120c32f80> [32]
         4 (400 bytes) <malloc in CRYPTO_zalloc 0x120c33080> [80]
            1 (208 bytes) <pthread_rwlock_t 0x120c33180> [208]
            2 (112 bytes) <malloc in CRYPTO_zalloc 0x120c330d0> [80]
               1 (32 bytes) <malloc in ecx_key_op 0x120c32f00> [32]
             
...
...
ADDITONAL ENTRIES SIMILAR TO ABOVE REDACTED
...

The context being allocated on this line is never released:

gen_ctx = ICC_EVP_PKEY_CTX_new(ockCtx,(ICC_EVP_PKEY *) ockPrivXecKey,NULL); /* Set private key */

jasonkatonica added a commit to jasonkatonica/OpenJCEPlus that referenced this issue Dec 11, 2024
The context allocated in the method `XECKEY.computeECDHSecret` was never
freed when a key was successfully generated. This update frees memory
associated with the context prior to return of the secret key bytes.

Whitespace and formatting was also done to make use of brackets for if
statements.

Fixes IBM#387

Signed-off-by: Jason Katonica <[email protected]>
@jasonkatonica jasonkatonica linked a pull request Dec 11, 2024 that will close this issue
jasonkatonica added a commit to jasonkatonica/OpenJCEPlus that referenced this issue Dec 18, 2024
The context allocated in the method `XECKEY.computeECDHSecret` was never
freed when a key was successfully generated. This update frees memory
associated with the context prior to return of the secret key bytes.

Whitespace and formatting was also done to make use of brackets for if
statements.

Fixes IBM#387

Signed-off-by: Jason Katonica <[email protected]>
jasonkatonica added a commit to jasonkatonica/OpenJCEPlus that referenced this issue Dec 18, 2024
The context allocated in the method `XECKEY.computeECDHSecret` was never
freed when a key was successfully generated. This update frees memory
associated with the context prior to return of the secret key bytes.

Whitespace and formatting was also done to make use of brackets for if
statements.

Fixes IBM#387

Signed-off-by: Jason Katonica <[email protected]>
jasonkatonica added a commit to jasonkatonica/OpenJCEPlus that referenced this issue Jan 2, 2025
The context allocated in the method `XECKEY.computeECDHSecret` was never
freed when a key was successfully generated. This update frees memory
associated with the context prior to return of the secret key bytes.

Whitespace and formatting was also done to make use of brackets for if
statements.

Fixes IBM#387

Signed-off-by: Jason Katonica <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant