shithub: opusfile

Info  •  Files  •  Log  •  Branches

Relax some assumptions about our seeking success.

There really isn't anything that guarantees we can find timestamps
 within the bounds of the link, or within 2 billion samples of the
 target, if people resort to nasty things like swapping out all of
 the underlying file data on us at the right moment.
Reported by clang's static analysis in
 https://github.com/xiph/opusfile/issues/16

Thanks to kcgen for filing the report.

--- a/src/opusfile.c

+++ b/src/opusfile.c

@@ -2654,11 +2654,12 @@

     ret=op_fetch_and_process_page(_of,NULL,-1,0,1);

     if(OP_UNLIKELY(ret<0))return OP_EBADLINK;

   }

-  OP_ALWAYS_TRUE(!op_granpos_diff(&diff,prev_packet_gp,pcm_start));

-  /*We skipped too far.

+  /*We skipped too far, or couldn't get within 2 billion samples of the target.

     Either the timestamps were illegal or there was a hole in the data.*/

-  if(diff>skip)return OP_EBADLINK;

-  OP_ASSERT(_pcm_offset-diff<OP_INT32_MAX);

+  if(op_granpos_diff(&diff,prev_packet_gp,pcm_start)||diff>skip

+   ||_pcm_offset-diff>=OP_INT32_MAX){

+    return OP_EBADLINK;

+  }

   /*TODO: If there are further holes/illegal timestamps, we still won't decode

      to the correct sample.

     However, at least op_pcm_tell() will report the correct value immediately