UaF in DeferredTaskHandler::BreakConnections(2)
Chrome
CVE-2020-6449
Chrome version: master branch build 79956ba, asan build 80.3987.132 Operating System: Ubuntu 18.04
This issue has the same crash site as 1057593, but the root cause and the fix is different.
Similar to 1057593, when a suspend of the BaseAudioContext
and a stop of an AudioScheduleSourceNode
happens in the same quantum, the AudioScheduleSourceNode
can be destroyed while the BaseAudioContext
is suspended. At this point, active_source_handlers_
in DeferredTaskHandler
[1] is responsible for keeping the corresponding AudioScheduleSourceHandler
alive before it is used in DeferredTaskHandler::BreakConnections
[2].
The code in DeferredTaskHandler::BreakConnections
implicitly assumed that finished_source_handlers_
is a subset of active_source_handlers_
and hence active_source_handlers_
is keeping the raw pointers in finished_source_handlers_
alive. (as can be seen from the active_source_handlers_.erase
, which assumes finished
is contained in active_source_handlers_
)
This problem, however, is that active_source_handlers_
can be cleared by the DeferredTaskHandler::ClearHandlersToBeDeleted
method[3] while finished_source_handlers_
does not get cleared at the same time, leaving dangling pointers in finished_source_handlers_
, which will then cause UaF in BreakConnections
.
for (auto* finished : finished_source_handlers_) {
// Break connection first and then remove from the list because that can
// cause the handler to be deleted.
finished->BreakConnectionWithLock(); //<-- `active_source_handlers_` may have been cleared, and finished is already freed
active_source_handlers_.erase(finished); //<-- assumes `active_source_handlers_` contains finished
}
By destroying the context to trigger BaseAudioContext::Uninitialize
, which will then call ClearHandlersToBeDeleted
, it is possible to clear active_source_handlers_
and then trigger DeferredTaskHandler::BreakConnections
to cause a UaF.
Use-after-free in renderer.
This issue was discovered and reported by GHSL team member @m-y-mo (Man Yue Mo).
You can contact the GHSL team at securitylab@github.com
, please include the GHSL-2020-040
in any communication regarding this issue.