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

(chore) free memory using asn1_time_free when asn1_time_set is used #11

Closed

Conversation

vinayakhulawale
Copy link
Contributor

For consistency using time_free instead of string_free

@fffonion
Copy link
Owner

@vinayakhulawale types like ASN1_*TIME and ASN1_INTEGER are actually all stored as ASN.1 encoded string (ASN1_STRING), the types basically control different routines when parsing. For example if you want to parse the string into a integer, you pass in an ASN1_INTEGER and expect a integer to return. In fact the openssl manaul also suggests using ASN1_STRING_free on those types.
My thought will be if we want to go with this path, we should use this pattern everywhere for consistency. Considering we will likely consult openssl manual in the future, I would doubt if there's a good path to pursue
Regarding free there's no difference in each variants.

@vinayakhulawale
Copy link
Contributor Author

@fffonion - yep, manual does say we can use ASN1_STRING_free to free memory for ASN1_TIME structure but I feel it would be more consistent to use ASN1_TIME_free when we explicitly use ASN1_TIME* .

I was checking openssl tests, they use both approaches (time_free and string_free), Libraries like luaossl sticks to time_free

@vinayakhulawale
Copy link
Contributor Author

I am OK to close this PR, if you want to use string_free. Also if you are OK with time_free usage - I can modify script and other occurrences too.

@vinayakhulawale
Copy link
Contributor Author

@fffonion - did you get chance to decide if you want to go with time_free or stick to string_free ?

@fffonion
Copy link
Owner

fffonion commented Sep 4, 2020

@vinayakhulawale I'll still say to use STRING_free here, let's keep in sync with manual. Thanks for your contribution!

@fffonion fffonion closed this Sep 4, 2020
zhuizhuhaomeng added a commit to zhuizhuhaomeng/lua-resty-openssl that referenced this pull request Jul 22, 2024
READ of size 4 at 0x60300004fba8 thread T0
    #0 0x7ffff6d96fb4 in BN_get_word crypto/bn/bn_lib.c:411
    fffonion#1 0x555555ca9d98  (/usr/local/openresty-plus-asan/nginx/sbin/nginx+0x755d98)
    fffonion#2 0x555555d7149f in lj_ccall_func /usr/src/debug/openresty-plus-1.19.9.1.65/build/LuaJIT-plus-2.1-20240710/src/lj_ccall.c:1402
    fffonion#3 0x555555ca35b7 in lj_cf_ffi_meta___call /usr/src/debug/openresty-plus-1.19.9.1.65/build/LuaJIT-plus-2.1-20240710/src/lib_ffi.c:230
    fffonion#4 0x555555ca7773  (/usr/local/openresty-plus-asan/nginx/sbin/nginx+0x753773)
    fffonion#5 0x55555599e140 in ngx_http_lua_run_thread ../ngx_lua-0.10.26.8/src/ngx_http_lua_util.c:1190
    fffonion#6 0x5555559a9d21 in ngx_http_lua_content_by_chunk ../ngx_lua-0.10.26.8/src/ngx_http_lua_contentby.c:124
    fffonion#7 0x55555575d41d in ngx_http_core_content_phase src/http/ngx_http_core_module.c:1269
    fffonion#8 0x555555748024 in ngx_http_core_run_phases src/http/ngx_http_core_module.c:885
    fffonion#9 0x55555577348d in ngx_http_process_request src/http/ngx_http_request.c:2130
    fffonion#10 0x5555557749a6 in ngx_http_process_request_headers src/http/ngx_http_request.c:1529
    fffonion#11 0x5555557758c4 in ngx_http_process_request_line src/http/ngx_http_request.c:1196
    fffonion#12 0x55555570fb1c in ngx_epoll_process_events src/event/modules/ngx_epoll_module.c:968
    fffonion#13 0x5555556e5706 in ngx_process_events_and_timers src/event/ngx_event.c:262
    fffonion#14 0x55555570b323 in ngx_single_process_cycle src/os/unix/ngx_process_cycle.c:338
    fffonion#15 0x555555660ef4 in main src/core/nginx.c:403
    fffonion#16 0x7ffff683feaf in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    fffonion#17 0x7ffff683ff5f in __libc_start_main_impl ../csu/libc-start.c:389
    fffonion#18 0x5555556648f4 in _start (/usr/local/openresty-plus-asan/nginx/sbin/nginx+0x1108f4)

0x60300004fba8 is located 8 bytes inside of 24-byte region [0x60300004fba0,0x60300004fbb8)
freed by thread T0 here:
    #0 0x7ffff74b46b7 in free (/lib64/libasan.so.6+0xb46b7)
    fffonion#1 0x7ffff6ea66e7 in CRYPTO_free crypto/mem.c:312
    fffonion#2 0x7ffff6d9810e in BN_free crypto/bn/bn_lib.c:231
    fffonion#3 0x555555ca9d98  (/usr/local/openresty-plus-asan/nginx/sbin/nginx+0x755d98)
    fffonion#4 0x555555d7149f in lj_ccall_func /usr/src/debug/openresty-plus-1.19.9.1.65/build/LuaJIT-plus-2.1-20240710/src/lj_ccall.c:1402
    fffonion#5 0x555555ca35b7 in lj_cf_ffi_meta___call /usr/src/debug/openresty-plus-1.19.9.1.65/build/LuaJIT-plus-2.1-20240710/src/lib_ffi.c:230
    fffonion#6 0x555555ca7773  (/usr/local/openresty-plus-asan/nginx/sbin/nginx+0x753773)

previously allocated by thread T0 here:
    #0 0x7ffff74b4a07 in __interceptor_malloc (/lib64/libasan.so.6+0xb4a07)
    fffonion#1 0x7ffff6ea66bc in CRYPTO_malloc crypto/mem.c:222
    fffonion#2 0x7ffff6ea6807 in CRYPTO_zalloc crypto/mem.c:230
    fffonion#3 0x7ffff6d96c15 in BN_new crypto/bn/bn_lib.c:246
    fffonion#4 0x555555ca9d98  (/usr/local/openresty-plus-asan/nginx/sbin/nginx+0x755d98)
    fffonion#5 0x555555d7149f in lj_ccall_func /usr/src/debug/openresty-plus-1.19.9.1.65/build/LuaJIT-plus-2.1-20240710/src/lj_ccall.c:1402
    fffonion#6 0x555555ca35b7 in lj_cf_ffi_meta___call /usr/src/debug/openresty-plus-1.19.9.1.65/build/LuaJIT-plus-2.1-20240710/src/lib_ffi.c:230
    fffonion#7 0x555555ca7773  (/usr/local/openresty-plus-asan/nginx/sbin/nginx+0x753773)
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 this pull request may close these issues.

2 participants