[FFmpeg-devel] [PATCH] avcodec/htmlsubtitles: Be a bit more picky on syntax

Michael Niedermayer michael at niedermayer.cc
Sun Jul 9 00:07:48 EEST 2017


On Mon, Jul 03, 2017 at 05:50:08PM +0200, Michael Niedermayer wrote:
> On Mon, Jul 03, 2017 at 12:40:13PM +0200, wm4 wrote:
> > On Sun, 2 Jul 2017 13:43:57 +0200
> > Michael Niedermayer <michael at niedermayer.cc> wrote:
> > 
> > > On Sun, Jul 02, 2017 at 01:14:00PM +0200, wm4 wrote:
> > > > On Sun,  2 Jul 2017 00:09:42 +0200
> > > > Michael Niedermayer <michael at niedermayer.cc> wrote:
> > > >   
> > > > > This reduces the number of strstr() calls per byte
> > > > > This diasalows empty tags like '< >' as well as '<' in tags like '<ab<cd<<ef>'
> > > > > 
> > > > > Fixes timeout
> > > > > Fixes: 1817/clusterfuzz-testcase-minimized-5104230530547712
> > > > > 
> > > > > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> > > > > ---
> > > > >  libavcodec/htmlsubtitles.c | 4 ++--
> > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
> > > > > index be5c9316ca..67abc94085 100644
> > > > > --- a/libavcodec/htmlsubtitles.c
> > > > > +++ b/libavcodec/htmlsubtitles.c
> > > > > @@ -110,13 +110,13 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst, const char *in)
> > > > >          case '<':
> > > > >              tag_close = in[1] == '/';
> > > > >              len = 0;
> > > > > -            if (sscanf(in+tag_close+1, "%127[^>]>%n", buffer, &len) >= 1 && len > 0) {
> > > > > +            if (sscanf(in+tag_close+1, "%127[^<>]>%n", buffer, &len) >= 1 && len > 0) {
> > > > >                  const char *tagname = buffer;
> > > > >                  while (*tagname == ' ')
> > > > >                      tagname++;
> > > > >                  if ((param = strchr(tagname, ' ')))
> > > > >                      *param++ = 0;
> > > > > -                if ((!tag_close && sptr < FF_ARRAY_ELEMS(stack)) ||
> > > > > +                if ((!tag_close && sptr < FF_ARRAY_ELEMS(stack) && *tagname) ||
> > > > >                      ( tag_close && sptr > 0 && !strcmp(stack[sptr-1].tag, tagname))) {
> > > > >                      int i, j, unknown = 0;
> > > > >                      in += len + tag_close;  
> > > > 
> > > > Invalid syntax is not unusual in SRT files. Are you sure this doesn't
> > > > make the output worse in files that do not use the syntax correctly?  
> > > 
> > > I do not know if this makes the output worse for files with invalid syntax
> > > I also do not know if this makes the output better for files with invalid
> > > syntax
> > > 
> > > i dont have a large library of (real world invalid syntax) srt files
> > > whith which to find cases where it makes a difference.
> > > 
> > > You seem to know alot about srt, maybe you can pick some srt files
> > > and add fate tests, so we have better coverage of odd and nasty cases
> > > 
> > > about this patch specifically, what do you suggest ?
> > > should i try to fix this while maintaining existing behavior for
> > > invalid syntax exactly? (i dont know how that code would look)
> > > 
> > > [...]
> > 
> > I don't know either, but due to the messy syntax situation, I'd rather
> > not change the code in unpredictable ways just to get faster fuzzing.
> 
> Its primarly intended to fix the potential denial of service.
> That is moderate sized files with short duration, few streams, low
> resolution, low channel count should not consume huge amounts of
> cpu time.

5 days passed with no comments and no suggestions on how to implement
this better.
does anyone object to the fix as in the patch to be applied ?

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170708/a0a41902/attachment.sig>


More information about the ffmpeg-devel mailing list