[Privoxy-devel] PATCH for pcre2 support

[Gagan Sidhu]

your previous message has me thinking about ’stack corruption’. it’s possible that the discovery below is related to that.

problem is i don’t know how to fix it, nor do i know how a change in library could cause this.

isn’t possible that most of the problems ‘downstream’ are a result of the issue below? 
	-the wrong size for the subject string would seem to screw up a lot of things, no?

— 

by the way, i have updated the patch since the JIT macro check was wrong.

the latest sha256 for the sourceforge attachment is now 9ed41077f6d0c59b73ca1655bdc00f825049077c5bcd3879c6f0e967a3c2a163

Thanks,
Gagan

> On Mar 18, 2023, at 4:04 PM, Gagan Sidhu <broly at mac.com> wrote:
> 
> whoops i forgot the last line in the pcre1 printout, so to be clear, this is what i’m getting:
> 
> pcre2:
> 
> 
>> Process 42798 stopped
>> * thread #2, stop reason = step over
>>   frame #0: 0x000000010000dd12 privoxy`template_fill(template_ptr=0x00000001004005e8, exports=0x0000000100400530) at cgi.c:2040:13
>>  2037	   /*
>>  2038	    * Assemble pcrs joblist from exports map
>>  2039	    */
>> -> 2040	   for (m = exports->first; m != NULL; m = m->next)
>>  2041	   {
>>  2042	      if (*m->name == '$')
>>  2043	      {
>> Target 0: (privoxy) stopped.
>> (lldb) print size
>> (size_t) $7 = 1
>> (lldb) print strlen(file_buffer)
>> error: 'strlen' has unknown return type; cast the call to its declared return type
>> (lldb) print (size_t) strlen(file_buffer)
>> (size_t) $8 = 15987
>> (lldb) print (size_t) strlen(file_buffer) + 1
>> (unsigned long) $9 = 15988
> 
> 
> pcre1:
>> Process 42869 stopped
>> * thread #2, stop reason = step over
>>    frame #0: 0x000000010000db0f privoxy`template_fill(template_ptr=0x00000001007001b8, exports=0x0000000100700170) at cgi.c:2040:13
>>   2037	   /*
>>   2038	    * Assemble pcrs joblist from exports map
>>   2039	    */
>> -> 2040	   for (m = exports->first; m != NULL; m = m->next)
>>   2041	   {
>>   2042	      if (*m->name == '$')
>>   2043	      {
>> Target 0: (privoxy) stopped.
>> (lldb) print size
>> (size_t) $1 = 15988
> 
>> (lldb) print strlen(file_buffer)
>> error: 'strlen' has unknown return type; cast the call to its declared return type
>> (lldb) print (size_t) strlen(file_buffer)
>> (size_t) $2 = 15987
>> (lldb) print (size_t) strlen(file_buffer) + 1
>> (unsigned long) $3 = 15988
> 
> Thanks,
> Gagan
> 
>> On Mar 18, 2023, at 4:02 PM, Gagan Sidhu <broly at mac.com> wrote:
>> 
>> i am doing some stepping through, and everything looks okay, until we enter template_fill
>> 
>> from what i’m seeing (and you should check this on your end as well), this “super efficient” approach of using one variable to pass, and later-on store,  the result of pcrs_execute *MAY* be the problem.
>> 	
>>> int pcrs_execute(pcrs_job *job, const char *subject, size_t subject_length, char **result, size_t *result_length)
>> 
>> in pcre2:
>>> Process 42798 stopped
>>> * thread #2, stop reason = step over
>>>   frame #0: 0x000000010000dd12 privoxy`template_fill(template_ptr=0x00000001004005e8, exports=0x0000000100400530) at cgi.c:2040:13
>>>  2037	   /*
>>>  2038	    * Assemble pcrs joblist from exports map
>>>  2039	    */
>>> -> 2040	   for (m = exports->first; m != NULL; m = m->next)
>>>  2041	   {
>>>  2042	      if (*m->name == '$')
>>>  2043	      {
>>> Target 0: (privoxy) stopped.
>>> (lldb) print size
>>> (size_t) $7 = 1
>>> (lldb) print strlen(file_buffer)
>>> error: 'strlen' has unknown return type; cast the call to its declared return type
>>> (lldb) print (size_t) strlen(file_buffer)
>>> (size_t) $8 = 15987
>>> (lldb) print (size_t) strlen(file_buffer) + 1
>>> (unsigned long) $9 = 15988
>> 
>> so, for some reason or another, lldb can print the strlen and display it, but the program is not reflecting this.
>> 
>> in the pcre1 version, no problem at all:
>> 
>>> Process 42869 stopped
>>> * thread #2, stop reason = step over
>>>   frame #0: 0x000000010000db0f privoxy`template_fill(template_ptr=0x00000001007001b8, exports=0x0000000100700170) at cgi.c:2040:13
>>>  2037	   /*
>>>  2038	    * Assemble pcrs joblist from exports map
>>>  2039	    */
>>> -> 2040	   for (m = exports->first; m != NULL; m = m->next)
>>>  2041	   {
>>>  2042	      if (*m->name == '$')
>>>  2043	      {
>>> Target 0: (privoxy) stopped.
>> 
>> i thank you for sharing your wisdom by immediately going to gdb, reminding me of its great value in these circumstances.
>> 
>> my proposal going forward:
>> 
>> 1. please reproduce my findings
>> 2. produce a patch that is not “overly-economic” so that subject_length and result_length have their own memory
>> 	-it’s possible the optimisations are causing the issue, i’m not sure.
>> 
>> in theory i don’t see why your approach is problematic for pcre2, this is why i’m thinking it’s some optimisation that clobbers the contents.
>> 
>> i guess the most important thing is the first step: can you reproduce my findings?
>> 	-if you can, then we have found the problem and i think it’s an easy fix.
>> 
>> whatcha think fabez?
>> 
>> Thanks,
>> Gagan
>> 
>> 
> 
> _______________________________________________
> Privoxy-devel mailing list
> Privoxy-devel at lists.privoxy.org
> https://lists.privoxy.org/mailman/listinfo/privoxy-devel