segfault in some cases when used init_worker_by_lua_block

[tierpod]

Hello. In some cases init_worker_by_lua_block cause nginx segfault

nginx[31582]: segfault at 8 ip 00007f4a21b29adb sp 00007ffcbbda6720 error 4 in ngx_http_lua_module.so[7f4a21af2000+54000]

Nginx core dump:

Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `nginx: master process /usr/sbin/nginx -c'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f0b103fea0b in ngx_http_lua_init_worker (cycle=<optimized out>) at lua-nginx-module-master/src/ngx_http_lua_initworkerby.c:216
216	            if (ngx_modules[i]->index == ngx_http_lua_module.index) {
(gdb) bt
#0  0x00007f0b103fea0b in ngx_http_lua_init_worker (cycle=<optimized out>) at lua-nginx-module-master/src/ngx_http_lua_initworkerby.c:216
#1  0x000055d0534e4cf6 in ngx_worker_process_init (cycle=cycle@entry=0x55d053bb6300, worker=worker@entry=0) at src/os/unix/ngx_process_cycle.c:931
#2  0x000055d0534e5186 in ngx_worker_process_cycle (cycle=cycle@entry=0x55d053bb6300, data=data@entry=0x0) at src/os/unix/ngx_process_cycle.c:735
#3  0x000055d0534e368b in ngx_spawn_process (cycle=cycle@entry=0x55d053bb6300, proc=proc@entry=0x55d0534e5160 <ngx_worker_process_cycle>, data=data@entry=0x0, 
    name=name@entry=0x55d053747d6e "worker process", respawn=respawn@entry=-3) at src/os/unix/ngx_process.c:199
#4  0x000055d0534e4890 in ngx_start_worker_processes (cycle=cycle@entry=0x55d053bb6300, n=1, type=type@entry=-3) at src/os/unix/ngx_process_cycle.c:359
#5  0x000055d0534e5ba3 in ngx_master_process_cycle (cycle=cycle@entry=0x55d053bb6300) at src/os/unix/ngx_process_cycle.c:131
#6  0x000055d0534bcd7f in main (argc=<optimized out>, argv=<optimized out>) at src/core/nginx.c:382

I can reproduce it on one of our servers, which was updated to centos 7 and nginx 1.17 a day ago. But I can't reproduce it on freshly installed VM.

• Software versions:

  CentOS Linux release 7.7.1908 (Core)
  nginx version: nginx/1.17.6
  lua-nginx-module from master
  

• A minimal and standalone test case that others can easily run on their side and
  reproduce the issue you are seeing:

  I have added init_worker_by_lua_block to my nginx configuration (empty or not - it does not matter). After nginx restart, I looked at /var/log/messages and there are many nginx workers segfaults.

Also, I've investigated file ngx_http_lua_initworkerby.c near line 216 and it seems like a bug:

1. on lines 197-201 modules variable was defined based on nginx_version:

lua-nginx-module/src/ngx_http_lua_initworkerby.c

Lines 197 to 220 in 760f707

	#if (nginx_version >= 1009011)
	modules = cycle->modules;
	#else
	modules = ngx_modules;
	#endif
	for (i = 0; modules[i]; i++) {
	if (modules[i]->type != NGX_HTTP_MODULE) {
	continue;
	}
	module = modules[i]->ctx;
	if (module->create_main_conf) {
	cur = module->create_main_conf(&conf);
	if (cur == NULL) {
	return NGX_ERROR;
	}
	if (ngx_modules[i]->index == ngx_http_lua_module.index) {
	ngx_memcpy(cur,
	conf_ctx->main_conf[ngx_http_lua_module.ctx_index],
	sizeof(ngx_http_lua_main_conf_t));
	}

2. but later on line 216 you use ngx_modules[i]->index instead of modules variable

So I prepared the small patch that fixed issue with nginx segfaults in my case:

diff --git a/src/ngx_http_lua_initworkerby.c b/src/ngx_http_lua_initworkerby.c
index 5b345280..7e8c3db5 100644
--- a/src/ngx_http_lua_initworkerby.c
+++ b/src/ngx_http_lua_initworkerby.c
@@ -213,7 +213,7 @@ ngx_http_lua_init_worker(ngx_cycle_t *cycle)
                 return NGX_ERROR;
             }
 
-            if (ngx_modules[i]->index == ngx_http_lua_module.index) {
+            if (modules[i]->index == ngx_http_lua_module.index) {
                 ngx_memcpy(cur,
                            conf_ctx->main_conf[ngx_http_lua_module.ctx_index],
                            sizeof(ngx_http_lua_main_conf_t));

PS: I'll make PR if you want

[thibaultcha]

Hi,

Thank you for the report. Your fix is correct, however, the commit containing this code was reverted due to an ongoing discussion in #1553. By the way, you should avoid deploying unreleased versions of this module.