On Fri, Apr 15, 2022 at 4:21 PM Stefan Eissing <ste...@eissing.org> wrote:
>
> > Am 15.04.2022 um 15:24 schrieb Yann Ylavic <ylavic....@gmail.com>:
> >
> > On Wed, Apr 6, 2022 at 11:17 AM <ic...@apache.org> wrote:
> >>
> >> Modified: httpd/httpd/trunk/server/util.c
> >> URL:
> >> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util.c?rev=1899609&r1=1899608&r2=1899609&view=diff
> >> ==============================================================================
> >> --- httpd/httpd/trunk/server/util.c (original)
> >> +++ httpd/httpd/trunk/server/util.c Wed Apr 6 09:17:42 2022
> >> @@ -2615,7 +2615,7 @@ AP_DECLARE(void) ap_content_type_tolower
> >> */
> >> AP_DECLARE(char *) ap_escape_quotes(apr_pool_t *p, const char *instring)
> >> {
> >> - int newlen = 0;
> >> + apr_ssize_t extra = 0;
> >
> > Shouldn't it be an apr_size_t?
>
> Similar comment raised on the PR https://github.com/apache/httpd/pull/298
Oh, I missed it.
>
> Not totally sure. The thing is that C in general has a problem with
> strings where ptrdiff_t (apr_ssize_t) is not sufficient. Allocating something
> larger than ptridff_t leads to undefined behaviour.
On 32bit systems, ssize_t = ptrdiff_t = int, I think allocating
something larger than INT_MAX is possible if you have the memory
available for it.
>
> So, maybe we should check that "(inchr - instring) + extra + 1" does not
> wrap around?
Maybe something like:
apr_size_t size, extra = 0;
...
size = inchr - instring + 1;
ap_assert(size + extra > size);
size += extra;
?
