Hi, yes, it helps a bit, since now the length is 69 on my side as well. However, I still cannot see the buffer overflow, since the offset is 64. The value (OP_KET) is also correct.
Could you print the re after the "re = (REAL_PCRE *)(PUBL(malloc))(size);" and common->start and GET(common->start, 1) as well? If the offset is really incorrect, probably common->start-re will not be equal to 56. Regards, Zoltan Ralf Junker <ralfjun...@gmx.de> írta: >On 13.05.2013 12:36, Zoltán Herczeg wrote:> > > this is quite interesting. Am I see right, that your pattern only contains > two fixed characters (backslash and space)? On a 32 bit Linux system, in 8 > bit mode, that is 67 bytes long (56 bytes for header, 11 for pattern) instead > of 69. That read access reads byte 63, which is perfect.> > The pattern contains, without leading / trailing slahes:> > \Q\ \E> > The core pattern is one backslash and one space each.> > > This is the interesting part:> > size = sizeof(REAL_PCRE) + (length + cd->names_found * cd->name_entry_size) * > sizeof(pcre_uchar);> > > > Could you print sizeof(REAL_PCRE), length, and size here?> > After this line, the numbers are as follows:> > sizeof(REAL_PCRE) = 56> length = 13> size = 69> > Does it matter that I compile with LINK_SIZE=3 ?> > Yes, it does. If I recompile with LINK_SIZE=2 (the default), I get these> numbers:> > sizeof(REAL_PCRE) = 56> length = 11> size = 69> > Does this help?> > Ralf> -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
