Bug#821321: libvorbisfile: ov_pcm_seek wrongly returns OV_EOF or segfaults sometimes

Frank Heckenbach f.heckenbach at fh-soft.de
Sun Apr 17 16:56:40 UTC 2016


Package: libvorbisfile3
Version: 1.3.4-2
Severity: important

ov_pcm_seek wrongly returns OV_EOF or segfaults sometimes. I've
observed it in some situations, below is a very simple one to
reproduce. It's an important problem to me, because (unless fixed or
you can tell me exactly when seeking will work), I'd have to treat
all Ogg/Vorbis files as unseekable in my code, which would be a huge
performance penalty (decoding sequentially and buffering all in
memory).

% cat test.c
#include <stdio.h>
#include <vorbis/vorbisfile.h>

int main ()
{
  OggVorbis_File vf;
  fprintf (stderr, "%i\n", ov_fopen ("foo.ogg", &vf));
  fprintf (stderr, "%i\n", ov_pcm_seek (&vf, 0));
  fprintf (stderr, "%i\n", ov_pcm_seek (&vf, 0));
  return 0;
}
% head -c 100000 /dev/zero|oggenc -Q -r - -o foo.ogg&& gcc -g test.c -lvorbisfile && ./a.out

On i386:
0
0
-2

On amd64:
0
0
Segmentation fault

I tried to debug it and found: The 2nd time ov_pcm_seek_is_called
(from the 2nd ov_pcm_seek call), at line 1461

      if(bisect!=vf->offset){
        result=_seek_helper(vf,bisect);
        if(result) goto seek_error;
      }

begin == 3997 and vf->offset == 3997, so the call to _seek_helper is
skipped. However, ftell((FILE*)vf->datasource) == 4076, so it goes
on with a wrong file position, so _get_next_page fails and og
remains unintialized and ogg_page_serialno(&og) (line 1554) results
in UB.

I don't really understand the code: Telling from this line,
vf->offset should reflect the actual position of the data source.
But if so, I'd expect it to be adjusted after each successfull call
of seek_func (that's correctly done) and read_func. read_func is
only called from _get_data, but it doesn't adjust vf->offset.
Instead it puts the data into an internal buffer AFAIUI, so the
users of the data from the buffer are probably responsible for
adjusting vf->offset, but apparently something goes wrong there.

If I just set vf->offset to 4076 before line 1461 (2nd time), it
continues correctly. That's of course, not a fix, just an indication
that the wrong value of vf->offset is the real problem here.

Maybe vf->offset just needs to be revalidated before line 1461, but
it's used in many places, and I don't know how many of them might be
affected too.

-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libvorbisfile3:amd64 depends on:
ii  libc6              2.19-18+deb8u4
ii  libogg0            1.3.2-1
ii  libvorbis0a        1.3.4-2
ii  multiarch-support  2.19-18+deb8u4

libvorbisfile3:amd64 recommends no packages.

libvorbisfile3:amd64 suggests no packages.

-- no debconf information



More information about the pkg-xiph-maint mailing list