You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, libhv is a very good open source library, recently I am learning the source code of libhv. While reading the http server code, I found a thread safety issue that may cause coredump, so I want to confirm it with you. The problem is described as follows:
(1) Pre-scenario: libhv's http server supports asynchronous response, that is, its own thread in the upper layer to use HttpResponseWriterPtr to write data to HttpResponsePtr.
At the same time, libhv support keep-alive, namely in the connection I received a new request, will call an HttpHandler: : FeedRecvData function, then the request to reset the old data.
(2) Reproduction method: When the upper-layer asynchronously calls HttpResponseWriterPtr to write the response data, if the customer sends the data again (can be http-pipeline or attack), the state of HttpHandler is not equal to WANT_RECV, Then call HttpHandler::Reset, and then call HttpMessage::Reset(), which will empty some object data.These data is not done thread-safe, so in the upper layer with HttpResponseWriterPtr modification, may cause segment errors.
Hope to get your reply:
(1) Whether the scene of this problem exists.
(2) If so, can it be optimized?
Hello, libhv is a very good open source library, recently I am learning the source code of libhv. While reading the http server code, I found a thread safety issue that may cause coredump, so I want to confirm it with you. The problem is described as follows:
(1) Pre-scenario: libhv's http server supports asynchronous response, that is, its own thread in the upper layer to use HttpResponseWriterPtr to write data to HttpResponsePtr.
At the same time, libhv support keep-alive, namely in the connection I received a new request, will call an
HttpHandler: : FeedRecvData
function, then the request to reset the old data.(2) Reproduction method: When the upper-layer asynchronously calls HttpResponseWriterPtr to write the response data, if the customer sends the data again (can be http-pipeline or attack), the state of HttpHandler is not equal to WANT_RECV, Then call
HttpHandler::Reset
, and then callHttpMessage::Reset()
, which will empty some object data.These data is not done thread-safe, so in the upper layer with HttpResponseWriterPtr modification, may cause segment errors.Hope to get your reply:
(1) Whether the scene of this problem exists.
(2) If so, can it be optimized?
很抱歉我的英文表达能力不是很好,以下是issue的中文描述:
您好,libhv是一个非常优秀的开源库,最近我在学习libhv的源码。在阅读http服务器代码的时候,发现了一个可能会引发coredump的线程安全问题,因此想跟您确认一下。问题描述如下:
(1)前置场景:libhv的http server是支持异步响应的,也就是在上层自己的线程去使用HttpResponseWriterPtr写入数据到HttpResponsePtr。
同时,libhv也支持keep-alive,也就是在连接收到新的请求时,会进入
HttpHandler::FeedRecvData
函数,然后去reset旧的请求的数据。(2)复现方式:在上层异步调用HttpResponseWriterPtr写入响应数据时,如果这时候客户再次发送数据过来(可以是http-pipeline,也可以是攻击),这时候会HttpHandler的state不等于WANT_RECV,然后会调用
HttpHandler::Reset
,进而调用HttpMessage::Reset()
,这里会清空一些对象的数据,因为这些数据是没有做线程安全的,因此在上层用HttpResponseWriterPtr修改的时候,可能会导致段错误。希望能得到您的答复:
(1)这个问题的场景是否存在。
(2)如果存在,能否优化呢?
The text was updated successfully, but these errors were encountered: