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? 2nd: could such mime headers be the reason for a pcre pattern to let libpcre segfault? -- Cheers tobi Am 12.05.20 um 15:20 schrieb Wietse Venema: > Tobi: >> Hi list >> >> we have the very rare problem that cleanup "triggers" segfaults in >> libpcre. We're currently running postfix 3.5.1 but had the issue before >> updating (with postfix 3.4.4) as well. OS is a Centos7 with latest updates. >> >>> May 12 14:36:14 XXX kernel: cleanup[23927]: segfault at 7ffc5118ef78 >>> ip 00007fd07913c98a sp 00007ffc5118ef70 error 6 in >>> libpcre.so.1.2.0[7fd079129000+60000] >> >> libpcre is of version 8.32 >> >> Unfortunately we do not have access to the message source. But it's >> always the same message that triggers the segfault. Every re-send try >> from sending server ends in that error. >> We highly assume that one of our pcre rules could be the culprit, but >> it's hard to find out which one it is. Postfix never complains about a >> broken pattern or something like that in logs. Also testing with postmap >> -vv -q works without any error/warning for all our pcre maps. There is >> no suspicious logging prior to cleanup "crash". >> >> Is there a way to narrow down which pcre rule may is problematic, given >> the fact that we do not have access to message source? > > Use dummy rules: > > /(.+)/ info before foo: $1 > /foo/ action for foo > /(.+)/ info before bar > /bar/ action for bar > > Wietse >
signature.asc
Description: OpenPGP digital signature
