Loobenyang

The issue is related to a use-after-free vulnerability in the WebRTC socket thread, allowing remote attackers to execute arbitrary code by leveraging incorrect free operations on DTLS objects during the shutdown of a WebRTC session. This occurs due to the incorrect use of memory after it has been freed.

The issue is related to a race condition in the get implementation of the ServiceWorkerManager class in the Service Worker subsystem. This condition arises due to insufficient checking of the resource state when it can be shared. Exploitation of this issue may allow a remote attacker to execute arbitrary code or cause a denial of service, such as a buffer overflow leading to an application crash, by using a specially crafted web site.

The issue is related to the ServiceWorkerManager class and can be exploited by remote attackers to execute arbitrary code or cause a denial of service, resulting in out-of-bounds read and memory corruption. This is achieved through unspecified use of the Clients API.

The issue is related to a use-after-free vulnerability, which occurs when memory is accessed after it has been freed. This can be exploited by a remote attacker to execute arbitrary code when attempting to use a data channel that has been closed by a WebRTC function.

The issue is related to a race condition in the WorkerPrivate::NotifyFeatures function, which can be exploited by remote attackers to execute arbitrary code or cause a denial of service. This is due to improper interaction between shared workers and the IndexedDB implementation, leading to use-after-free and application crash.

A use-after-free issue in the XMLHttpRequest::Open implementation might allow remote attackers to execute arbitrary code via a SharedWorker object that makes recursive calls to the open method of an XMLHttpRequest object. This could potentially lead to the execution of arbitrary code.

The issue is related to a use-after-free vulnerability in the CanonicalizeXPCOMParticipant function. This vulnerability can be exploited by a remote attacker to execute arbitrary code by manipulating the `XMLHttpRequest` function, specifically by attaching an `XMLHttpRequest` object to a shared worker.

The issue is related to a use-after-free vulnerability in the CanonicalizeXPCOMParticipant function. This vulnerability can be exploited by a remote attacker to execute arbitrary code by manipulating the `XMLHttpRequest` function, specifically by attaching an `XMLHttpRequest` object to a dedicated worker.