From 8b84365c81df734d29fe724cd6e1ec3807fe2926 Mon Sep 17 00:00:00 2001 From: Henrik Lundin Date: Mon, 26 Feb 2018 09:44:44 +0100 Subject: [PATCH] NetEq: Guarding against reading outside of memory In rare and pathological circumstances, it could happen that the input length to the merge function is very short. This CL will avoid one of the problems with out-of-bounds read that could result from this. Bug: chromium:799499 Change-Id: I6bde105ae88f9d130764b6dfb3d25443d07e214b Reviewed-on: https://webrtc-review.googlesource.com/57582 Reviewed-by: Ivo Creusen Commit-Queue: Henrik Lundin Cr-Commit-Position: refs/heads/master@{#22180} --- modules/audio_coding/neteq/merge.cc | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/modules/audio_coding/neteq/merge.cc b/modules/audio_coding/neteq/merge.cc index 9bc509b907..b568ff0e83 100644 --- a/modules/audio_coding/neteq/merge.cc +++ b/modules/audio_coding/neteq/merge.cc @@ -291,7 +291,12 @@ void Merge::Downsample(const int16_t* input, size_t input_length, decimation_factor, kCompensateDelay); if (input_length <= length_limit) { // Not quite long enough, so we have to cheat a bit. - size_t temp_len = input_length - signal_offset; + // If the input is really short, we'll just use the input length as is, and + // won't bother with correcting for the offset. This is clearly a + // pathological case, and the signal quality will suffer. + const size_t temp_len = input_length > signal_offset + ? input_length - signal_offset + : input_length; // TODO(hlundin): Should |downsamp_temp_len| be corrected for round-off // errors? I.e., (temp_len + decimation_factor - 1) / decimation_factor? size_t downsamp_temp_len = temp_len / decimation_factor;