Re: svn commit: r1931148 - httpd/httpd/trunk/modules/dav/main

Joe Orton <[email protected]> Mon, 12 Jan 2026 10:16:57 +0000

Newsgroups	gmane.comp.apache.devel
Organization	Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US)
Message-ID	<[email protected]>

On Wed, Jan 07, 2026 at 09:08:54AM +0100, Ruediger Pluem wrote:
> On 1/6/26 12:02 PM, [email protected] wrote:
> > Author: jorton
> > Date: Tue Jan  6 11:02:20 2026
> > New Revision: 1931148
...
> > +    /* Validate PROPPATCH length against configured limits */
> > +    limit = ap_get_limit_xml_body(r);
> > +    if (limit > 0 && proppatch_len > limit) {
> > +        return dav_new_error(r->pool, HTTP_REQUEST_ENTITY_TOO_LARGE, 0, 0,
> > +                             "PROPPATCH part length exceeds configured limit");
> > +    }
> > +    if (proppatch_len <= 0 || proppatch_len > (apr_off_t)APR_SIZE_MAX) {
> 
> How can proppatch_len be larger than APR_SIZE_MAX?
> 
> IMHO the maximum value of proppatch_len being an apr_off_t is 9,223,372,036,854,775,807
> APR_SIZE_MAX is the maximum value of apr_size_t which is 18,446,744,073,709,551,615.
> Or should this guard against cases of 32 bit systems with _FILE_OFFSET_BITS=64 or
> _LARGEFILE64_SOURCE set where apr_off_t is 64 bit and apr_size_t 32 bit? If yes it is
> probably worth documenting this in a comment.

Sorry, I had some e-mail problems last week so I think my reply went to 
/dev/null.

Good questions - because ap_get_limit_xml_body() already imposes a 
maximum which is a fraction of APR_SIZE_MAX that second test is 
definitely redundant. Fixed in r1931184.

Regards, Joe