Fixes use after free error when setting a new FrameEncryptor on ChannelSend.
This change corrects a potential race condition when updating a FrameEncryptor
for the audio send channel. If a FrameEncryptor is set on an active audio
stream it is possible for the current FrameEncryptor attached to the audio channel to be deallocated due to
the FrameEncryptors reference count reaching zero before the new FrameEncryptor is set on the
channel.
To address this issue the ChannelSend is now holds a scoped_reftptr<FrameEncryptor>
to only allow deallocation when it is actually set on the encoder queue.
ChannelSend is unique in this respect as the Audio Receiver a long with the
Video Sender and Video Receiver streams all recreate themselves when they have
a configuration change. ChannelSend instead reconfigures itself using the
existing channel object.
Added Seth as TBR as this only introduces mocks.
TBR=shampson@webrtc.org
Bug: webrtc:9907
Change-Id: Ibf391dc9cecdbed1874e0252ff5c2cb92a5c64f4
Reviewed-on: https://webrtc-review.googlesource.com/c/107664
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25374}diff --git a/audio/channel_send.cc b/audio/channel_send.cc
index 83350c4..7d01a4d 100644
--- a/audio/channel_send.cc
+++ b/audio/channel_send.cc
@@ -993,14 +993,15 @@
return rtt;
}
-void ChannelSend::SetFrameEncryptor(FrameEncryptorInterface* frame_encryptor) {
+void ChannelSend::SetFrameEncryptor(
+ rtc::scoped_refptr<FrameEncryptorInterface> frame_encryptor) {
rtc::CritScope cs(&encoder_queue_lock_);
if (encoder_queue_is_active_) {
encoder_queue_->PostTask([this, frame_encryptor]() {
- this->frame_encryptor_ = frame_encryptor;
+ this->frame_encryptor_ = std::move(frame_encryptor);
});
} else {
- frame_encryptor_ = frame_encryptor;
+ frame_encryptor_ = std::move(frame_encryptor);
}
}