LuaSec for x64? #14
Comments
|
+1 for a x64 version. |
|
Any news for x64 support? (more one year after) |
|
luasec has always worked on x64. EDIT: noticed the original post refers to .dll; are you talking about windows support? |
|
Sorry, but I'm not confortable to provide pre-compiled packages for luasec since I barely use Windows to test. |
Zash
added a commit
to Zash/luasec
that referenced
this issue
Aug 12, 2021
Background:
The SSL Context has a reference to the Lua state, commonly called L, for
use when invoking callbacks during TLS handshaking.
Earlier there was a crash due to the Lua State having changed between
context creation and access to it during TLS handshake. This could
happen if the TLS context is created in one coroutine, which has
subsequently been garbage collected and its memory become invalid,
whereafter the TLS context is used to negotiate a TLS connection which
involves calling some callback.
Observation:
SIGSEGV in alpn_cb(), where arg/ctx -> L does not match the L earlier in
the stack, in meth_handshake().
#0 __strcmp_sse2 () at ../sysdeps/x86_64/strcmp.S:1447
lunarmodules#1 0x00005589415b1e1a in luaS_new (L=L@entry=0x5589444880a8, str=str@entry=0x7ff3f94b160e "SSL:ALPN:Registry") at lstring.c:246
lunarmodules#2 0x00005589415a47b2 in auxgetstr (L=0x5589444880a8, t=0x558944488188, k=k@entry=0x7ff3f94b160e "SSL:ALPN:Registry") at lapi.c:617
lunarmodules#3 0x00005589415a575b in lua_getfield (L=L@entry=0x5589444880a8, idx=idx@entry=-1001000, k=k@entry=0x7ff3f94b160e "SSL:ALPN:Registry") at lapi.c:657
lunarmodules#4 0x00007ff3f94af3c5 in alpn_cb (s=<optimized out>, out=0x7ffdda0dc260, outlen=0x7ffdda0dc25f "", in=0x558943d14570 "\vxmpp-client", inlen=12, arg=0x55894450d2a8) at src/context.c:660
lunarmodules#5 0x00007ff3f946751c in tls_handle_alpn (s=0x558943d6d540) at ../ssl/statem/statem_srvr.c:2147
lunarmodules#6 0x00007ff3f944ddd8 in tls_parse_all_extensions (s=s@entry=0x558943d6d540, context=context@entry=128, exts=<optimized out>, x=x@entry=0x0, chainidx=chainidx@entry=0, fin=fin@entry=1) at ../ssl/statem/extensions.c:761
lunarmodules#7 0x00007ff3f94677bc in tls_early_post_process_client_hello (s=0x558943d6d540) at ../ssl/statem/statem_srvr.c:1881
lunarmodules#8 tls_post_process_client_hello (s=0x558943d6d540, wst=<optimized out>) at ../ssl/statem/statem_srvr.c:2225
lunarmodules#9 0x00007ff3f945726b in read_state_machine (s=0x558943d6d540) at ../ssl/statem/statem.c:664
lunarmodules#10 state_machine (s=0x558943d6d540, server=1) at ../ssl/statem/statem.c:434
lunarmodules#11 0x00007ff3f9442f74 in SSL_do_handshake (s=0x558943d6d540) at ../ssl/ssl_lib.c:3615
lunarmodules#12 0x00007ff3f94ad44f in handshake (ssl=0x558944811648) at src/ssl.c:120
lunarmodules#13 meth_handshake (L=0x5589432a2268) at src/ssl.c:388
lunarmodules#14 0x00005589415a8e61 in luaD_precall (L=L@entry=0x5589432a2268, func=func@entry=0x558944223f20, nresults=2) at ldo.c:503
(gdb) frame 13
lunarmodules#13 meth_handshake (L=0x5589432a2268) at src/ssl.c:388
(gdb) p ctx
$1 = (p_context) 0x5589433ab508
This is passed as 'arg' to alpn_cb(), note different pointer
arg=0x55894450d2a8.
Theory:
When selecting a context during SNI negotiation, the selected context
would be a different one from the one where meth_handshake() has updated
the Lua state reference. Thus the reference can still be invalid and
cause a crash when invoving a callback afterwards, such as the ALPN one.
Solution:
Update the Lua state reference on the selected SSL context after SNI.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have managed to run Luasec under x86 (32-bit) but I could not build it to run under x64, SSL.dll is not found, could you please provide a build?
The text was updated successfully, but these errors were encountered: