Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2021-04-03 Thread Michael Niedermayer
On Thu, Apr 01, 2021 at 09:22:23PM +0200, Paul B Mahol wrote: > Try this attached patch. I have not looked at all samples, as some allocate > too much memory for my system. > But this patch points where real bugs are, unlike yours patch which hides > real bugs even more. > cfhd.c |7 ++-

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2021-04-02 Thread Paul B Mahol
I do not have time or motivation to deal with this and similar issues. But applying band-aid solutions are not step forward. On Fri, Apr 2, 2021 at 12:53 AM Michael Niedermayer wrote: > On Fri, Apr 02, 2021 at 12:49:26AM +0200, Michael Niedermayer wrote: > > On Fri, Apr 02, 2021 at 12:25:53AM

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2021-04-01 Thread Michael Niedermayer
On Fri, Apr 02, 2021 at 12:49:26AM +0200, Michael Niedermayer wrote: > On Fri, Apr 02, 2021 at 12:25:53AM +0200, Michael Niedermayer wrote: > > On Thu, Apr 01, 2021 at 09:22:23PM +0200, Paul B Mahol wrote: > > > Try this attached patch. I have not looked at all samples, as some > > > allocate > >

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2021-04-01 Thread Michael Niedermayer
On Fri, Apr 02, 2021 at 12:25:53AM +0200, Michael Niedermayer wrote: > On Thu, Apr 01, 2021 at 09:22:23PM +0200, Paul B Mahol wrote: > > Try this attached patch. I have not looked at all samples, as some allocate > > too much memory for my system. > > > But this patch points where real bugs are,

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2021-04-01 Thread Michael Niedermayer
On Thu, Apr 01, 2021 at 09:22:23PM +0200, Paul B Mahol wrote: > Try this attached patch. I have not looked at all samples, as some allocate > too much memory for my system. > But this patch points where real bugs are, unlike yours patch which hides > real bugs even more. I would appreciate if

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2021-04-01 Thread Paul B Mahol
Try this attached patch. I have not looked at all samples, as some allocate too much memory for my system. But this patch points where real bugs are, unlike yours patch which hides real bugs even more. From fc4abcc0d0058ea8a7cd79ce26bfbcbed4cf5329 Mon Sep 17 00:00:00 2001 From: Paul B Mahol Date:

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2021-03-31 Thread Paul B Mahol
I can not reproduce any crash either with address sanitizer or valgrind with samples you provided. Are you sure this apply to master? On Tue, Mar 30, 2021 at 7:50 PM Paul B Mahol wrote: > Please share files privately, do not apply non fix for this issue. > > Give up with such this non-solution.

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2021-03-30 Thread Paul B Mahol
Please share files privately, do not apply non fix for this issue. Give up with such this non-solution. On Tue, Mar 30, 2021 at 6:49 PM Michael Niedermayer wrote: > On Sun, Dec 20, 2020 at 10:15:24PM +0100, Michael Niedermayer wrote: > > This is based on the encoder and a small number of CFHD

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2021-03-30 Thread Michael Niedermayer
On Sun, Dec 20, 2020 at 10:15:24PM +0100, Michael Niedermayer wrote: > This is based on the encoder and a small number of CFHD sample files > It should make the decoder more robust against crafted input. > Due to the lack of a proper specification it is possible that this > may be too strict and

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2020-12-23 Thread Paul B Mahol
On Wed, Dec 23, 2020 at 3:59 PM Michael Niedermayer wrote: > On Wed, Dec 23, 2020 at 10:52:03AM +0100, Paul B Mahol wrote: > > On Tue, Dec 22, 2020 at 10:27 PM Michael Niedermayer > > > wrote: > > > > > On Sun, Dec 20, 2020 at 10:18:40PM +0100, Paul B Mahol wrote: > > > > Unacceptable, please

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2020-12-23 Thread Michael Niedermayer
On Wed, Dec 23, 2020 at 10:52:03AM +0100, Paul B Mahol wrote: > On Tue, Dec 22, 2020 at 10:27 PM Michael Niedermayer > wrote: > > > On Sun, Dec 20, 2020 at 10:18:40PM +0100, Paul B Mahol wrote: > > > Unacceptable, please share privately sample that allows to reproduce > > this. > > > > shared

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2020-12-23 Thread Paul B Mahol
On Tue, Dec 22, 2020 at 10:27 PM Michael Niedermayer wrote: > On Sun, Dec 20, 2020 at 10:18:40PM +0100, Paul B Mahol wrote: > > Unacceptable, please share privately sample that allows to reproduce > this. > > shared the ones which reproduce. > > Please explain why this patch is unacceptable to

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2020-12-22 Thread Michael Niedermayer
On Sun, Dec 20, 2020 at 10:18:40PM +0100, Paul B Mahol wrote: > Unacceptable, please share privately sample that allows to reproduce this. shared the ones which reproduce. Please explain why this patch is unacceptable to you. the CFHD decoder decodes header elements in the order in which they

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2020-12-20 Thread Paul B Mahol
Unacceptable, please share privately sample that allows to reproduce this. On Sun, Dec 20, 2020 at 10:16 PM Michael Niedermayer wrote: > This is based on the encoder and a small number of CFHD sample files > It should make the decoder more robust against crafted input. > Due to the lack of a

[FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2020-12-20 Thread Michael Niedermayer
This is based on the encoder and a small number of CFHD sample files It should make the decoder more robust against crafted input. Due to the lack of a proper specification it is possible that this may be too strict and may need to be tuned as files not following this ordering are found. Fixes: