On Tue, 2017-04-25 at 00:10 +0200, Matthias Brinke wrote:
> I've run-tested a hopefully-final version of my patch fixing
> CVE-2017-5853 (tested with the original reproducer PDF file
> using the test program whose source is also attached)
Hi,
I wasn't able to reproduce the CVE-2017-5853, a
Hi Mark, hi all,
I've run-tested a hopefully-final version of my patch fixing
CVE-2017-5853 (tested with the original reproducer PDF file
using the test program whose source is also attached) and two
other CVEs (sorry, I didn't have enough time to test those)
probably also, so please review, test
The revised patch doesn’t compile because it uses:
+PODOFO_ERROR_INFO( ePdfError_ValueOutOfRange,
+"xref subsection's given entry numbers together too large" );
instead of
+PODOFO_RAISE_ERROR_INFO ( ePdfError_ValueOutOfRange,
+"xref subsect
Hi all,
I'm sorry if that wasn't clear: the caveats about my knowledge
I gave in my answer to Mark still apply. I'd also like to know
the CVE he has patches for include CVE-2017-6840 and CVE-2017-6842
because I'd like to work on those if not, when I next have time.
(Basically, protect the graphics
Hi zyx, hi all,
I've replaced the asserts with PODOFO_RAISE_ERROR_INFO calls
in if checks and removed the size_t check (replacing it with
a check more to the point and C++-like), so I hope the change
is now ready for inclusion as attached to this e-mail (or maybe
with minor edits still crediting m
On Sat, 2017-04-08 at 18:32 +0200, Matthew Brincke wrote:
> +PODOFO_ASSERT( nFirstObject > 0 );
Hi,
I do not like asserts, unless being used in unit tests or such places.
Especially this place is used to parse random data from outside, which
the library has no control of, then it's not
Hi Mark, hi all,
> Mark Rogers has written on 8 April 2017 at
> 10:01:
>
> Hi
>
> There are the CVEs in ReadXRefSubsection:
>
> CVE-2017-6844 global buffer overflow in PdfParser::ReadXRefSubsection
> CVE-2017-5855 NULL pointer dereference in PdfParser::ReadXRefSubsection
> CVE-2017-5853 signe
Hi
There are the CVEs in ReadXRefSubsection:
CVE-2017-6844 global buffer overflow in PdfParser::ReadXRefSubsection
CVE-2017-5855 NULL pointer dereference in PdfParser::ReadXRefSubsection
CVE-2017-5853 signed integer overflow in PdfParser.cpp
CVE-2017-6844 and CVE-2017-5853 are caused by 3 relate
Hi zyx, hi all,
I've addressed the below concerns, and run-tested as I could, pity
my GCC 5.2.1 didn't find a difference with/out patch with the option
-fsanitize=undefined, except for my diagnostic message ;-(. I used
the same test program as earlier. Please review the patch attached.
> zyx has
Hi zyx, hi all,
Matthew Brincke has written on 1 March 2017 at 00:22:
> By the Robustness Principle/Postel's Law ("Be strict in what you send,
> but generous in what you receive") I wanted to hint at PoDoFo maybe going to
> support more objects than what the standard suggests (!) for 32-bit syste
Hi zyx, hi all,
> zyx has written on 28 February 2017 at 08:38:
>
>
> On Tue, 2017-02-28 at 00:14 +0100, Matthew Brincke wrote:
> > I haven't completed testing yet
>
> Hi,
> thanks for the patch. Just from a quick read of the proposed change:
>
> > +const pdf_int64 maxNum
> > +
On Tue, 2017-02-28 at 00:14 +0100, Matthew Brincke wrote:
> I haven't completed testing yet
Hi,
thanks for the patch. Just from a quick read of the proposed change:
> +const pdf_int64 maxNum
> + = static_cast(std::numeric_limits::max());
As far as I know, 'long' type is architec
Hi all,
attached to the e-mail is a patch which I propose to fix CVE-2017-5853 and
maybe also CVE-2017-5855.
I haven't completed testing yet, but I have also already seen by running some
test code, also attached,
that my patch catches the bogus xref subsection start in the reproducer PDF
(linke
13 matches
Mail list logo
