Mark Baker wrote:
There is a limit recursion feature of PCRE, which the calling program
could use.
There appears to be two options here:
1) Punt back to Konqueror, and get them (or whatever they're calling
that uses libpcre3 - note that libpcre3 is *not* in the dependancies of
konqueror 4:3.5.5a.dfsg.1-2, so this probably needs doing somewhere
else) and get them to use the recursion limiting of pcre to clip it at a
few thousand - your stack trace got to 8156 iterations, so clipping at
say 4000 or so should be plenty for most sane things while not limiting
most applications. This is a bit of a hack around, but would fix the
security issue (well, unless some user sets their stack size even smaller)
2) Figure out a way to fix this properly by getting libpcre to realise
it's run out of stack space (possibly by not spawning new copies of
match() unless there's some minimum value of stack free), and to return
some form of "match failed badly, here's an error" up to the calling
app. Not sure how you'd do that cleanly offhand. Catching SIGSEGV might
work, but would be like using a sledgehammer to crack peanuts (as well
as screwing with any application that's catching SIGSEGV for it's own
reasons). Best option here is probably forwarding to upstream and seeing
what their thoughts are. I guess as the package maintainer you're
probably on the mailing list for them?
Tom Parker
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
