Re: Segmentation fault в DAV модуле

Maxim Dounin mdounin at mdounin.ru
Tue Nov 20 09:21:56 UTC 2012


Hello!

On Tue, Nov 20, 2012 at 12:05:07PM +0300, Dmitry Petrov wrote:

> On Mon, Nov 19, 2012 at 7:40 PM, Arnaud GRANAL <serphen at gmail.com> wrote:
> 
> > I guess it was fixed in a recent commit by Maxim:
> > [..]
> > diff --git a/src/http/modules/ngx_http_dav_module.c
> > b/src/http/modules/ngx_http_dav_module.c
> > --- a/src/http/modules/ngx_http_dav_module.c
> > +++ b/src/http/modules/ngx_http_dav_module.c
> > @@ -209,6 +209,11 @@ ngx_http_dav_put_handler(ngx_http_reques
> >      ngx_ext_rename_file_t     ext;
> >      ngx_http_dav_loc_conf_t  *dlcf;
> >
> > +    if (r->request_body == NULL || r->request_body->temp_file == NULL) {
> > +        ngx_http_finalize_request(r, NGX_HTTP_INTERNAL_SERVER_ERROR);
> > +        return;
> > +    }
> > +
> >      ngx_http_map_uri_to_path(r, &path, &root, 0);
> >
> >      path.len--;
> >
> The problem is that I got this behavior on sequential valid PUT requests.
> After handling first request, nginx even doesn't try to read body of next
> request. It just calls ngx_http_dav_put_handler with r->response_body from

It looks like this is a generic request body handling problem, 
which leads to incorrect body processing if an extra write event 
happens during request body reading.

The patch quoted will fix resulting segfault in dav module (which 
may also happen in other conditions), but the underlying problem 
also needs to be fixed.  If you have a test case to reproduce the 
problem it might be helpful.

> previous request but with r->response_body->temp_file set to NULL. With
> extra check for temp_file not being NULL nginx actually reads second
> request body and handles it properly.

The extra check you've added isn't correct as 
r->response_body->temp_file may be NULL for valid reasons, e.g.  
request body reading is done by a normal module like proxy, which 
doesn't require request body to be in file.

-- 
Maxim Dounin
http://nginx.com/support.html



More information about the nginx-devel mailing list