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
