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

-------------- 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