[cairo-bugs] [Bug 100763] Cairo-1.15.4 Denial-of-Service Attack due to Logical Problem in Program

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu May 4 16:00:51 UTC 2017


https://bugs.freedesktop.org/show_bug.cgi?id=100763

--- Comment #5 from Jiaqi Peng <pengjiaqi at iie.ac.cn> ---
(In reply to Chris Wilson from comment #4)
> That was a lot of rigmarole where the simple gdb bt would suffice.
> 
> Issue stems from commit 79d975f84bcc32e91db517d71a7312e2e1d653d4
> Author: Behdad Esfahbod <behdad at behdad.org>
> Date:   Wed Sep 12 17:45:11 2007 -0400
> 
>     [cairo-ft-font] Ignore FT_Load_Glyph errors other than out-of-memory
>     Same for FT_Render_Glyph.
>     
>     When the user asks us to render a glyph that is not available in the
> font,
>     it's mostly an unavoidable kind of error for them, as in, they can't
>     avoid such a call.  So it's not nice to put cairo_t in an error state and
>     refuse any further drawying.
>     
>     Many PDF files are created using buggy software and cause such
> glpyh-not-fou
> nd
>     errors for CID 0 for example.
>     
>     Eventually we should propagate these kind of errors up and return it from
>     the function call causing it, but that needs API change to add return
> value
>     to all text functions, so for now we just ignore these errors.

I have sensed that you already make some consideration about the error
propagation. However the solution taken now really will cause some unexpected
results, such as the upper application using cairo may crash.

I report and disclosure this issue, so that the upper developers can pay some
attention to this problem and take some defense measures as soon as possible.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cairographics.org/archives/cairo-bugs/attachments/20170504/91efc687/attachment.html>


More information about the cairo-bugs mailing list