<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - [TAGGEDPDF] Parse the Tagged-PDF document structure tree when present" href="https://bugs.freedesktop.org/show_bug.cgi?id=64815#c21">Comment # 21</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - [TAGGEDPDF] Parse the Tagged-PDF document structure tree when present" href="https://bugs.freedesktop.org/show_bug.cgi?id=64815">bug 64815</a> from <a class="email" href="mailto:aacid@kde.org" title="Albert Astals Cid <aacid@kde.org>"> Albert Astals Cid</a> <pre>(In reply to <a href="show_bug.cgi?id=64815#c20">comment #20</a>) > (In reply to <a href="show_bug.cgi?id=64815#c12">comment #12</a>) > > [...] But I'll assume there's some tree structure parsing somewhere > > because PDF are full of those trees, are we protecting against loop > > in the tree somehow? > > I didn't see code in Poppler that would be particularly useful to parse > the document structure tree. WRT loops in the structure tree, there is > no protection and a malformed PDF file could potentially cause an > infinite loop when parsing the tree. If I am understanding the PDF spec > correctly, well-formed PDFs must not have loops in the tree. How critical > would you say having protection against loops in the tree would be? Quite critical, people usually spend their time writing such kind of pdf since that way they can make us crash (heap exhaustion) and thus they can say "whooooo i found a CVE in poppler"... That's why we have in various places the passing of std::set<int> with the refs of already parsed things in the tree so in case you find you have to process something that is already in the set you know you found a loop and simply bail out. It should not be very hard to add so it'd be cool if you could add it.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>