Hi Wietse using your suggestion with valgrind I found that the main-stacksize seems to be the problem. By using --main-stacksize with different values I found that the last working value is 59449345, changing to ...344 let postmap segfault:
> valgrind -s --main-stacksize=59449344 --tool=memcheck postmap -h -q - > pcre:/etc/postfix/mime_header_checks.pcre </tmp/borked_1.header > > ==7988== Stack overflow in thread #1: can't grow stack to 0x1ffb74f000 We will try allowing more stacksize by /etc/security/limits.conf to postfix and re-design our pcre pattern(s) to avoid (where possible) the usage of .* without any limits :-) Thanks a lot for your appreciated help -- Cheers tobi Am 13.05.20 um 16:05 schrieb Wietse Venema: > Tobi: >> Hi >> >> as usual: thanks to Wietse :-) >> >> Adding the info rule to the pcre maps solved more than expected. After >> adding the info rule postfix cleanup did not segfault anymore and the >> mail could be accepted --> we have the source now. >> From what I see that is a massively oversized mime part header. I >> counted about 500 times the filename= in the mime part header as well as >> name= contains hundreds of values. All nicely utf8 >> >> Like >> >>> Content-Type: image/png; name="=?UTF- >>> 8?B?xILChMOCwoLEgsKCw4LChMOEwoLDgsKCxILCgsOCwoLEgsKEw4LCgsSC?= >>> =?UTF-8?B?woLDgsKCw4TCgsOCwoLEgsKCw4LChMOEwoLDgsKExILCgsOCwoLDhMKC?= >>> =?UTF-8?B?w4LCgsSCwoLDgsKCxILChMOCwoLEgsKCw4LCgsOEwoLDgsKCxILCgsOC?= >> >> and >> >>> Content-Disposition: inline; filename*0*=UTF-8''%C4%82%C2%84%C3%82%C2 >>> %82%C4%82%C2%82%C3%82%C2%84%C3%84; >>> filename*1*=%C2%82%C3%82%C2%82%C4%82%C2%82%C3%82%C2%82%C4%82%C2%84 >>> %C3%82; >> >> First of all any idea why cleanup did not segfault with the info rule in >> place? > > When something accesses wrong memory, what happens next is totally > dependent on memory layout, execution history, and so on. For example > the program may not crash (but still produce incorrect behavior). > >> 2nd: could such mime headers be the reason for a pcre pattern to let >> libpcre segfault? > > Sure, there are sometimes bugfixes for libpcre. > > You can test such things. > > $ postmap -h -q - pcre:pattern-file < data-file > > $ valgrind --tool=memcheck postmap -h -q - pcre:pattern-file < data-file > > where data-file contains the complete crashing message header and > pattern-file contains the crashing pattern. > > Note that Postfix logs only a limited portion of very large lines. > You may need to "postcat" the original message if it is available. > > valgrind will report incorrect memory access even when a program > does not crash. And yes, I do sometimes run Postfix daemons under > valgrind to find non-crashing bugs. > > I'd be interested if you can reproduce the bug. > > Wietse >
