Remove raw pointers for Notification codes.
Categories
(Core :: DOM: Notifications, defect, P2)
Tracking
()
People
(Reporter: edenchuang, Assigned: edenchuang)
References
Details
Attachments
(1 file)
After WorkerRunnable refactoring (bug 1800659) landed, some assumptions are not valid anymore. Raw pointers in Notification codes could cause the problem and need to be fixed.
Updated•2 years ago
|
Comment 1•2 years ago
|
||
Assuming this is about replacing Notification*
with RefPtr<Notification>
.
Assignee | ||
Comment 2•2 years ago
|
||
It is a little bit more complicated than just replacing Notification* with RefPtr<Notification>
The root cause is the Notification code assumes that all NotificationWorkerRunnables execute Cancel() After a StrongWorkerRef gets a worker shutdown notification. And NotificationWorkerRunnable::Cancel() does nothing.
However, after bug 1800659, instead of calling Cancel(), call WorkerRun() to release resources. And NotificationWorkerRunnable::WorkerRun() could access some already released resources during WorkerRef::Notify(). So we meet UAF/Crash on these resources accessing.
This means the Notification code does not guarantee that NotificatiionWorkerRunnable's lifecycle is covered by a StrongWorkerRef. The StrongWorkerRef is freed too early in the Notification code.
Bug 1839231 and bug 1850843 change the NotificationWorkerRunnable's behavior to keep it doing nothing once the StrongWorkerRef is released by checking passed in WorkerPrivate's status. However, we should make the Notification code follow the Worker life-cycle policy(Always ensure the WorkerRunnable's life-cycle is covered by a StrongWorkerRef)
Replacing Notification* with RefPtr<Notification> should be one of the goals of this bug.
Comment 3•1 years ago
•
|
||
Thanks, that sounds like this needs one who is sufficiently expert in workers and runnables, are you going to work on this in the near future or do you want me to take a look?
Updated•11 months ago
|
Assignee | ||
Comment 8•5 months ago
|
||
Comment 9•2 months ago
|
||
Fixed by bug 1931497.
Description
•