Bug in ngx_http_slice_filter_module ngx_http_slice_parse_content_range function
Carey Gister
careygister at outlook.com
Thu Jun 27 02:01:27 UTC 2019
The ngx_http_slice_parse_content_range function assumes that the parsed buffer is null terminated. Since the buffer is an ngx_str_t, that assumption is false. If, by chance, the buffer is null terminated it is simply a matter of luck, and not design.
In particular, if the headers_out.content_range ngx_str_t was allocated in the ngx_http_range_filter_module then the buffer was allocated as a non-zero terminated buffer by ngx_pnalloc.
The fact that the buffer is not null terminated may lead to ngx_http_slice_parse_content_range returning an NGX_ERROR code after the buffer was successfully parsed, or, if
the caller is unfortunate, leading to a random memory access failure.
I've written a replacement function that uses the length of the ngx_str_t as a guard condition. This code works and passes all of the unit tests.
How should I submit the replacement?
Carey Gister
415-310-5304
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20190627/98181162/attachment.html>
More information about the nginx-devel
mailing list