Menu

#1505 check pointer

Undefined
wont-fix
nobody
None
Bug_Report
2024-12-06
2024-11-18
No

File:
/src/plugins/contrib/source_exporter/wxPdfDocument/src/pdfparser.cpp line 833

Code:
wxPdfStream stm = NULL;
if (object->GetType() == OBJTYPE_STREAM)
{
stm = (wxPdfStream
) object;
if (((wxPdfName) stm->Get(wxS("Type")))->GetName() != wxS("XRef"))
{
delete object;
return false;
}
}
int size = ((wxPdfNumber
) stm->Get(wxS("Size")))->GetInt(); // <-- better check pointer stm

Discussion

  • Miguel Gimenez

    Miguel Gimenez - 2024-11-19
    • status: open --> wont-fix
     
  • Miguel Gimenez

    Miguel Gimenez - 2024-11-19

    wxPdfDocument is an external library, we just update it from time to time

    Yon can post your issue here, Ulrich usually accepts corrections.

     
  • Ulrich Telle

    Ulrich Telle - 2024-11-24

    What is the problem? Did the application crash? If yes, provide a sample PDF document exposing the problem.
    At the point where "better check pointer stm" is asked for the pointer stm is already verified to be a pointer to an XRef stream and the attribute "Size" is a required attribute. If it doesn't exist, the PDF file is actually an invalid PDF file.

     
  • Martin Strunz

    Martin Strunz - 2024-11-25

    would be more defensive, but I think it is not present in the new wxPdfDocument version. So it is invalid.

     
    • Ulrich Telle

      Ulrich Telle - 2024-11-25

      Yes, it would be more defensive, I agree. However, this would be true for many PDF attribute accesses in the PDF parser code. For valid PDF files no crashes should occur. Only for broken PDF files crashes can be expected.

      Nevertheless I agree that even for broken PDF files a crash is not so nice. I will consider to update the parser code to avoid crashes (as it is done already for optional PDF attributes), even though they are unlikely to occur.

       
    • Ulrich Telle

      Ulrich Telle - 2024-11-25

      but I think it is not present in the new wxPdfDocument version.

      Can you please explain what is not present in the wxPdfDocument version?

      So it is invalid.

      What is invalid? The PDF for which you experienced a problem with the pasrer code? If yes, it would be of interest from which source the PDF originated.

       
  • Martin Strunz

    Martin Strunz - 2024-11-26

    I am not sure if the wxPdfDocument version is the same in Codeblocks.
    I consider it invalid because it is a refactoring.
    There is no test case it was just a source code scan.

     

    Last edit: Martin Strunz 2024-11-26
    • Ulrich Telle

      Ulrich Telle - 2024-11-26

      I am not sure if the wxPdfDocument version is the same in Codeblocks.

      The source exporter plugin of CodeBlocks uses version 1.0.2. The latest wxPdfDocument release is version 1.2.0. However, regarding this issue the versions don't make a noteworthy difference.

      I don't know whether CodeBlocks could update the included wxPdfDocument version easily, because the latest version requires wxWidgets version 3.2.x. However, I see traces of wxWidgets 3.2 support in the Code::Blocks source tree. So it should not be a big deal.

      There is no test case it was just a source code scan.

      Ok, good to know.

      Nevertheless as I said I will consider to rework the code for a future version.

       
      • Morten MacFly

        Morten MacFly - 2024-12-05

        I did update the code in trunk now to use v1.2.0. Seems to work just fine.

         
  • Martin Strunz

    Martin Strunz - 2024-12-06

    Perfect!

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.