Hi，春哥请教下关于ngx.exec调用的问题（导致vm崩溃）

jayce.liuchuan

线上环境：openresty-1.9.7.3 模块版本ngx_lua-0.10.0

原因是有一个特殊请求uri，如下：

/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini

使用了ngx.exec API跳转请求到别的location，内存疯涨后crash。

## 可复现最小化配置

   location / {
       content_by_lua_block {
           return ngx.exec("/error_page/../windows/win.ini")
       }
   }

查看nginx日志有报unsafe URI错误，看了ngx_http_lua_ngx_exec的代码片段定位到如下代码：

if (ngx_http_parse_unsafe_uri(r, &uri, &args, &flags)
   != NGX_OK)
{
   return NGX_HTTP_INTERNAL_SERVER_ERROR;
}

这个地方return 500 应该有问题的吧（vm的栈崩溃，还是别的问题呢？）

查看这个函数其他报错的地方都是调用的luaL_error API，是否应该这样使用呢？

doujiang24

Hello

在我本地的 1.11.2.1 并不能复现你说的问题呢？

遇到 coredump 的问题，我们一般可以按照这个顺序来自检：

1. 更新的最新版本复现，以确保不是已经修复过的 bug

2. 移除不必要的第三方模块，以排除第三方的问题

3. 准备完整的复现配置和步骤

4. 用 gdb 提供奔溃点的 backtrace

以下是我的配置和步骤

server {

listen 8090;

location / {

content_by_lua_block {

ngx.say("hello world!")

}

location /Object {

content_by_lua_block {

return ngx.exec("/foo")

}

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini"

<html>

<head><title>400 Bad Request</title></head>

<center><h1>400 Bad Request</h1></center>

<hr><center>openresty/1.11.2.1</center>

</body>

</html>

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc"

hello world!

在 2016年11月2日下午2:42，Jayce <jayce....@gmail.com>写道：

线上环境：openresty-1.9.7.3 模块版本ngx_lua-0.10.0

原因是有一个特殊请求uri，如下：
/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini
使用了ngx.exec API跳转请求到别的location，内存疯涨后crash。

## 可复现最小化配置

location / { content_by_lua_block { return ngx.exec("/error_page/../windows/win.ini") } }

查看nginx日志有报unsafe URI错误，看了ngx_http_lua_ngx_exec的代码片段定位到如下代码：
if (ngx_http_parse_unsafe_uri(r, &uri, &args, &flags) != NGX_OK) { return NGX_HTTP_INTERNAL_SERVER_ERROR; }

这个地方return 500 应该有问题的吧（vm的栈崩溃，还是别的问题呢？）
查看这个函数其他报错的地方都是调用的luaL_error API，是否应该这样使用呢？

--

jayce.liuchuan

Hello, 你把ngx.exec("/foo") 改为 ngx.exec("/foo/../") 试试。

在 2016年11月2日下午5:59，DeJiang Zhu <douj...@gmail.com>写道：

Hello

在我本地的 1.11.2.1 并不能复现你说的问题呢？

遇到 coredump 的问题，我们一般可以按照这个顺序来自检：

1. 更新的最新版本复现，以确保不是已经修复过的 bug
2. 移除不必要的第三方模块，以排除第三方的问题
3. 准备完整的复现配置和步骤
4. 用 gdb 提供奔溃点的 backtrace

以下是我的配置和步骤

server {
listen 8090;

location / {
content_by_lua_block {
ngx.say("hello world!")
}
}

location /Object {
content_by_lua_block {
return ngx.exec("/foo")
}
}
}

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini"
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>openresty/1.11.2.1</center>
</body>
</html>

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc"
hello world!

在 2016年11月2日下午2:42，Jayce <jayce....@gmail.com>写道：
线上环境：openresty-1.9.7.3 模块版本ngx_lua-0.10.0

原因是有一个特殊请求uri，如下：
/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini
使用了ngx.exec API跳转请求到别的location，内存疯涨后crash。

## 可复现最小化配置

location / { content_by_lua_block { return ngx.exec("/error_page/../windows/win.ini") } }

查看nginx日志有报unsafe URI错误，看了ngx_http_lua_ngx_exec的代码片段定位到如下代码：
if (ngx_http_parse_unsafe_uri(r, &uri, &args, &flags) != NGX_OK) { return NGX_HTTP_INTERNAL_SERVER_ERROR; }

这个地方return 500 应该有问题的吧（vm的栈崩溃，还是别的问题呢？）
查看这个函数其他报错的地方都是调用的luaL_error API，是否应该这样使用呢？

--

--

doujiang24

Hello

在 2016年11月2日下午6:03，Chuan Liu <jayce....@gmail.com>写道：

Hello, 你把ngx.exec("/foo") 改为 ngx.exec("/foo/../") 试试。

嗯嗯，下面这个就可以复现了

curl "http://127.0.0.1:8090/Object"

被你的 url 迷惑了...

下回请提供精简的复现用例 :(

在 2016年11月2日下午5:59，DeJiang Zhu <douj...@gmail.com>写道：
Hello

在我本地的 1.11.2.1 并不能复现你说的问题呢？

遇到 coredump 的问题，我们一般可以按照这个顺序来自检：

1. 更新的最新版本复现，以确保不是已经修复过的 bug
2. 移除不必要的第三方模块，以排除第三方的问题
3. 准备完整的复现配置和步骤
4. 用 gdb 提供奔溃点的 backtrace

以下是我的配置和步骤

server {
listen 8090;

location / {
content_by_lua_block {
ngx.say("hello world!")
}
}

location /Object {
content_by_lua_block {
return ngx.exec("/foo")
}
}
}

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini"
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>openresty/1.11.2.1</center>
</body>
</html>

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc"
hello world!

在 2016年11月2日下午2:42，Jayce <jayce....@gmail.com>写道：
线上环境：openresty-1.9.7.3 模块版本ngx_lua-0.10.0

原因是有一个特殊请求uri，如下：
/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini
使用了ngx.exec API跳转请求到别的location，内存疯涨后crash。

## 可复现最小化配置

location / { content_by_lua_block { return ngx.exec("/error_page/../windows/win.ini") } }

查看nginx日志有报unsafe URI错误，看了ngx_http_lua_ngx_exec的代码片段定位到如下代码：
if (ngx_http_parse_unsafe_uri(r, &uri, &args, &flags) != NGX_OK) { return NGX_HTTP_INTERNAL_SERVER_ERROR; }

这个地方return 500 应该有问题的吧（vm的栈崩溃，还是别的问题呢？）
查看这个函数其他报错的地方都是调用的luaL_error API，是否应该这样使用呢？

--

--

--

jayce.liuchuan

Sorry，我前面的那个URL有误导的嫌疑，其实和URL没有关系，只要ngx.exec参数带“/../”字符串，就会复现。

另外查看了代码，这个地方应该是忘了修改吧。

将ngx_http_lua_ngx_exec函数代码片段修改为以下代码就ok（按照ngx_http_lua_ngx_location_capture_multi函数逻辑修改就不会崩溃，但不知道是否修改正确，因为对vm虚拟机不了解）

rc = ngx_http_parse_unsafe_uri(r, &uri, &args, &flags);

if (rc != NGX_OK) {

dd("rc = %d", (int) rc);

return luaL_error(L, "unsafe uri in argument #1: %s", p);

}

在 2016年11月2日下午6:08，DeJiang Zhu <douj...@gmail.com>写道：

Hello

在 2016年11月2日下午6:03，Chuan Liu <jayce....@gmail.com>写道：
Hello, 你把ngx.exec("/foo") 改为 ngx.exec("/foo/../") 试试。

嗯嗯，下面这个就可以复现了

curl "http://127.0.0.1:8090/Object"

被你的 url 迷惑了...
下回请提供精简的复现用例 :(

在 2016年11月2日下午5:59，DeJiang Zhu <douj...@gmail.com>写道：
Hello

在我本地的 1.11.2.1 并不能复现你说的问题呢？

遇到 coredump 的问题，我们一般可以按照这个顺序来自检：

1. 更新的最新版本复现，以确保不是已经修复过的 bug
2. 移除不必要的第三方模块，以排除第三方的问题
3. 准备完整的复现配置和步骤
4. 用 gdb 提供奔溃点的 backtrace

以下是我的配置和步骤

server {
listen 8090;

location / {
content_by_lua_block {
ngx.say("hello world!")
}
}

location /Object {
content_by_lua_block {
return ngx.exec("/foo")
}
}
}

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini"
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>openresty/1.11.2.1</center>
</body>
</html>

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc"
hello world!

在 2016年11月2日下午2:42，Jayce <jayce....@gmail.com>写道：
线上环境：openresty-1.9.7.3 模块版本ngx_lua-0.10.0

原因是有一个特殊请求uri，如下：
/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini
使用了ngx.exec API跳转请求到别的location，内存疯涨后crash。

## 可复现最小化配置

location / { content_by_lua_block { return ngx.exec("/error_page/../windows/win.ini") } }

查看nginx日志有报unsafe URI错误，看了ngx_http_lua_ngx_exec的代码片段定位到如下代码：
if (ngx_http_parse_unsafe_uri(r, &uri, &args, &flags) != NGX_OK) { return NGX_HTTP_INTERNAL_SERVER_ERROR; }

这个地方return 500 应该有问题的吧（vm的栈崩溃，还是别的问题呢？）
查看这个函数其他报错的地方都是调用的luaL_error API，是否应该这样使用呢？

--

--

--

--

doujiang24

Hello

2016-11-02 18:21 GMT+08:00 Chuan Liu <jayce....@gmail.com>:

Sorry，我前面的那个URL有误导的嫌疑，其实和URL没有关系，只要ngx.exec参数带“/../”字符串，就会复现。

另外查看了代码，这个地方应该是忘了修改吧。
将ngx_http_lua_ngx_exec函数代码片段修改为以下代码就ok

是的，就是需要这么改，直接调用 luaL_error 让 Lua VM 抛出异常即可

欢迎提交 PR，记得添加测试用例哦 :)

（按照ngx_http_lua_ngx_location_capture_multi函数逻辑修改就不会崩溃，但不知道是否修改正确，因为对vm虚拟机不了解）

此处 return 的返回值，将是 Lua 侧将收到的返回值个数，很明显这个值是错误的

具体用法，你可以参考 shdict.c 里面 return 的处理

rc = ngx_http_parse_unsafe_uri(r, &uri, &args, &flags);
if (rc != NGX_OK) {
dd("rc = %d", (int) rc);

return luaL_error(L, "unsafe uri in argument #1: %s", p);
}

在 2016年11月2日下午6:08，DeJiang Zhu <douj...@gmail.com>写道：
Hello

在 2016年11月2日下午6:03，Chuan Liu <jayce....@gmail.com>写道：
Hello, 你把ngx.exec("/foo") 改为 ngx.exec("/foo/../") 试试。

嗯嗯，下面这个就可以复现了

curl "http://127.0.0.1:8090/Object"

被你的 url 迷惑了...
下回请提供精简的复现用例 :(

在 2016年11月2日下午5:59，DeJiang Zhu <douj...@gmail.com>写道：
Hello

在我本地的 1.11.2.1 并不能复现你说的问题呢？

遇到 coredump 的问题，我们一般可以按照这个顺序来自检：

1. 更新的最新版本复现，以确保不是已经修复过的 bug
2. 移除不必要的第三方模块，以排除第三方的问题
3. 准备完整的复现配置和步骤
4. 用 gdb 提供奔溃点的 backtrace

以下是我的配置和步骤

server {
listen 8090;

location / {
content_by_lua_block {
ngx.say("hello world!")
}
}

location /Object {
content_by_lua_block {
return ngx.exec("/foo")
}
}
}

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini"
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>openresty/1.11.2.1</center>
</body>
</html>

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc"
hello world!

在 2016年11月2日下午2:42，Jayce <jayce....@gmail.com>写道：
线上环境：openresty-1.9.7.3 模块版本ngx_lua-0.10.0

原因是有一个特殊请求uri，如下：
/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini
使用了ngx.exec API跳转请求到别的location，内存疯涨后crash。

## 可复现最小化配置

location / { content_by_lua_block { return ngx.exec("/error_page/../windows/win.ini") } }

查看nginx日志有报unsafe URI错误，看了ngx_http_lua_ngx_exec的代码片段定位到如下代码：
if (ngx_http_parse_unsafe_uri(r, &uri, &args, &flags) != NGX_OK) { return NGX_HTTP_INTERNAL_SERVER_ERROR; }

这个地方return 500 应该有问题的吧（vm的栈崩溃，还是别的问题呢？）
查看这个函数其他报错的地方都是调用的luaL_error API，是否应该这样使用呢？

--

--

--

--

--

jayce.liuchuan

OK

On Wednesday, November 2, 2016 at 6:41:40 PM UTC+8, doujiang wrote:

Hello

2016-11-02 18:21 GMT+08:00 Chuan Liu <jayce.l...@gmail.com>:
Sorry，我前面的那个URL有误导的嫌疑，其实和URL没有关系，只要ngx.exec参数带“/../”字符串，就会复现。

另外查看了代码，这个地方应该是忘了修改吧。
将ngx_http_lua_ngx_exec函数代码片段修改为以下代码就ok

是的，就是需要这么改，直接调用 luaL_error 让 Lua VM 抛出异常即可

欢迎提交 PR，记得添加测试用例哦 :)

（按照ngx_http_lua_ngx_location_capture_multi函数逻辑修改就不会崩溃，但不知道是否修改正确，因为对vm虚拟机不了解）

此处 return 的返回值，将是 Lua 侧将收到的返回值个数，很明显这个值是错误的
具体用法，你可以参考 shdict.c 里面 return 的处理

rc = ngx_http_parse_unsafe_uri(r, &uri, &args, &flags);
if (rc != NGX_OK) {
dd("rc = %d", (int) rc);

return luaL_error(L, "unsafe uri in argument #1: %s", p);
}

在 2016年11月2日下午6:08，DeJiang Zhu <douji...@gmail.com>写道：
Hello

在 2016年11月2日下午6:03，Chuan Liu <jayce.l...@gmail.com>写道：
Hello, 你把ngx.exec("/foo") 改为 ngx.exec("/foo/../") 试试。

嗯嗯，下面这个就可以复现了

curl "http://127.0.0.1:8090/Object"

被你的 url 迷惑了...
下回请提供精简的复现用例 :(

在 2016年11月2日下午5:59，DeJiang Zhu <douji...@gmail.com>写道：
Hello

在我本地的 1.11.2.1 并不能复现你说的问题呢？

遇到 coredump 的问题，我们一般可以按照这个顺序来自检：

1. 更新的最新版本复现，以确保不是已经修复过的 bug
2. 移除不必要的第三方模块，以排除第三方的问题
3. 准备完整的复现配置和步骤
4. 用 gdb 提供奔溃点的 backtrace

以下是我的配置和步骤

server {
listen 8090;

location / {
content_by_lua_block {
ngx.say("hello world!")
}
}

location /Object {
content_by_lua_block {
return ngx.exec("/foo")
}
}
}

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini"
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>openresty/1.11.2.1</center>
</body>
</html>

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc"
hello world!

在 2016年11月2日下午2:42，Jayce <jayce.l...@gmail.com>写道：
线上环境：openresty-1.9.7.3 模块版本ngx_lua-0.10.0

原因是有一个特殊请求uri，如下：
/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini
使用了ngx.exec API跳转请求到别的location，内存疯涨后crash。

## 可复现最小化配置

location / { content_by_lua_block { return ngx.exec("/error_page/../windows/win.ini") } }

查看nginx日志有报unsafe URI错误，看了ngx_http_lua_ngx_exec的代码片段定位到如下代码：
if (ngx_http_parse_unsafe_uri(r, &uri, &args, &flags) != NGX_OK) { return NGX_HTTP_INTERNAL_SERVER_ERROR; }

这个地方return 500 应该有问题的吧（vm的栈崩溃，还是别的问题呢？）
查看这个函数其他报错的地方都是调用的luaL_error API，是否应该这样使用呢？

--

--

--

--

--

pumulu

这都能发现，川

在 2016年11月2日星期三 UTC+8下午7:29:31，Jayce写道：

OK

On Wednesday, November 2, 2016 at 6:41:40 PM UTC+8, doujiang wrote:
Hello

2016-11-02 18:21 GMT+08:00 Chuan Liu <jayce.l...@gmail.com>:
Sorry，我前面的那个URL有误导的嫌疑，其实和URL没有关系，只要ngx.exec参数带“/../”字符串，就会复现。

另外查看了代码，这个地方应该是忘了修改吧。
将ngx_http_lua_ngx_exec函数代码片段修改为以下代码就ok

是的，就是需要这么改，直接调用 luaL_error 让 Lua VM 抛出异常即可

欢迎提交 PR，记得添加测试用例哦 :)

（按照ngx_http_lua_ngx_location_capture_multi函数逻辑修改就不会崩溃，但不知道是否修改正确，因为对vm虚拟机不了解）

此处 return 的返回值，将是 Lua 侧将收到的返回值个数，很明显这个值是错误的
具体用法，你可以参考 shdict.c 里面 return 的处理

rc = ngx_http_parse_unsafe_uri(r, &uri, &args, &flags);
if (rc != NGX_OK) {
dd("rc = %d", (int) rc);

return luaL_error(L, "unsafe uri in argument #1: %s", p);
}

在 2016年11月2日下午6:08，DeJiang Zhu <douji...@gmail.com>写道：
Hello

在 2016年11月2日下午6:03，Chuan Liu <jayce.l...@gmail.com>写道：
Hello, 你把ngx.exec("/foo") 改为 ngx.exec("/foo/../") 试试。

嗯嗯，下面这个就可以复现了

curl "http://127.0.0.1:8090/Object"

被你的 url 迷惑了...
下回请提供精简的复现用例 :(

在 2016年11月2日下午5:59，DeJiang Zhu <douji...@gmail.com>写道：
Hello

在我本地的 1.11.2.1 并不能复现你说的问题呢？

遇到 coredump 的问题，我们一般可以按照这个顺序来自检：

1. 更新的最新版本复现，以确保不是已经修复过的 bug
2. 移除不必要的第三方模块，以排除第三方的问题
3. 准备完整的复现配置和步骤
4. 用 gdb 提供奔溃点的 backtrace

以下是我的配置和步骤

server {
listen 8090;

location / {
content_by_lua_block {
ngx.say("hello world!")
}
}

location /Object {
content_by_lua_block {
return ngx.exec("/foo")
}
}
}

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini"
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>openresty/1.11.2.1</center>
</body>
</html>

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc"
hello world!

在 2016年11月2日下午2:42，Jayce <jayce.l...@gmail.com>写道：
线上环境：openresty-1.9.7.3 模块版本ngx_lua-0.10.0

原因是有一个特殊请求uri，如下：
/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini
使用了ngx.exec API跳转请求到别的location，内存疯涨后crash。

## 可复现最小化配置

location / { content_by_lua_block { return ngx.exec("/error_page/../windows/win.ini") } }

查看nginx日志有报unsafe URI错误，看了ngx_http_lua_ngx_exec的代码片段定位到如下代码：
if (ngx_http_parse_unsafe_uri(r, &uri, &args, &flags) != NGX_OK) { return NGX_HTTP_INTERNAL_SERVER_ERROR; }

这个地方return 500 应该有问题的吧（vm的栈崩溃，还是别的问题呢？）
查看这个函数其他报错的地方都是调用的luaL_error API，是否应该这样使用呢？

--

--

--

--

--

jayce.liuchuan

碰巧遇到了。-_-!

On Monday, November 7, 2016 at 10:28:10 AM UTC+8, 魏海通 wrote:

这都能发现，川

在 2016年11月2日星期三 UTC+8下午7:29:31，Jayce写道：
OK

On Wednesday, November 2, 2016 at 6:41:40 PM UTC+8, doujiang wrote:
Hello

2016-11-02 18:21 GMT+08:00 Chuan Liu <jayce.l...@gmail.com>:
Sorry，我前面的那个URL有误导的嫌疑，其实和URL没有关系，只要ngx.exec参数带“/../”字符串，就会复现。

另外查看了代码，这个地方应该是忘了修改吧。
将ngx_http_lua_ngx_exec函数代码片段修改为以下代码就ok

是的，就是需要这么改，直接调用 luaL_error 让 Lua VM 抛出异常即可

欢迎提交 PR，记得添加测试用例哦 :)

（按照ngx_http_lua_ngx_location_capture_multi函数逻辑修改就不会崩溃，但不知道是否修改正确，因为对vm虚拟机不了解）

此处 return 的返回值，将是 Lua 侧将收到的返回值个数，很明显这个值是错误的
具体用法，你可以参考 shdict.c 里面 return 的处理

rc = ngx_http_parse_unsafe_uri(r, &uri, &args, &flags);
if (rc != NGX_OK) {
dd("rc = %d", (int) rc);

return luaL_error(L, "unsafe uri in argument #1: %s", p);
}

在 2016年11月2日下午6:08，DeJiang Zhu <douji...@gmail.com>写道：
Hello

在 2016年11月2日下午6:03，Chuan Liu <jayce.l...@gmail.com>写道：
Hello, 你把ngx.exec("/foo") 改为 ngx.exec("/foo/../") 试试。

嗯嗯，下面这个就可以复现了

curl "http://127.0.0.1:8090/Object"

被你的 url 迷惑了...
下回请提供精简的复现用例 :(

在 2016年11月2日下午5:59，DeJiang Zhu <douji...@gmail.com>写道：
Hello

在我本地的 1.11.2.1 并不能复现你说的问题呢？

遇到 coredump 的问题，我们一般可以按照这个顺序来自检：

1. 更新的最新版本复现，以确保不是已经修复过的 bug
2. 移除不必要的第三方模块，以排除第三方的问题
3. 准备完整的复现配置和步骤
4. 用 gdb 提供奔溃点的 backtrace

以下是我的配置和步骤

server {
listen 8090;

location / {
content_by_lua_block {
ngx.say("hello world!")
}
}

location /Object {
content_by_lua_block {
return ngx.exec("/foo")
}
}
}

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini"
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>openresty/1.11.2.1</center>
</body>
</html>

curl "http://127.0.0.1:8090/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc"
hello world!

在 2016年11月2日下午2:42，Jayce <jayce.l...@gmail.com>写道：
线上环境：openresty-1.9.7.3 模块版本ngx_lua-0.10.0

原因是有一个特殊请求uri，如下：
/Object.getPreview/hj-img/MjEzODI2MzgxNDc3OTIyMDM4NDIwMjk1NzI4MDA1MC5qcGc=/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fwindows/win.ini
使用了ngx.exec API跳转请求到别的location，内存疯涨后crash。

## 可复现最小化配置

location / { content_by_lua_block { return ngx.exec("/error_page/../windows/win.ini") } }

查看nginx日志有报unsafe URI错误，看了ngx_http_lua_ngx_exec的代码片段定位到如下代码：
if (ngx_http_parse_unsafe_uri(r, &uri, &args, &flags) != NGX_OK) { return NGX_HTTP_INTERNAL_SERVER_ERROR; }

这个地方return 500 应该有问题的吧（vm的栈崩溃，还是别的问题呢？）
查看这个函数其他报错的地方都是调用的luaL_error API，是否应该这样使用呢？

--

--

--

--

--