Bugzilla

### Security Approval Request
* **How easily could an exploit be constructed based on the patch?**: It's not hard to infer when the data race causing an UAF can happen by reading this patch carefully.
* **Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?**: Yes
* **Which older supported branches are affected by this flaw?**: For new Rust backend, it's FF74. For C backend, it exists for a long time.
* **If not all supported branches, which bug introduced the flaw?**: None
* **Do you have backports for the affected branches?**: Yes
* **If not, how different, hard to create, and risky will they be?**: For Rust cubeb backend, this patch can be uplifted to the FF74 easily.
For C cubeb backend, it's easy to import this change from the Rust backend to C backend.

However, the cubeb code are in public github repos. 
- main cubeb repo: https://github.com/kinetiknz/cubeb
- Rust cubeb on Mac OSx: https://github.com/ChunMinChang/cubeb-coreaudio-rs
The update will be submitted in github repos instead of being updated in the gecko directly. I am not sure how to hide the security vulnerability properly when updating the code. (One thing I can do is to update the code without commit messages or comments. The comments can be added in other separated commits anyway.)
* **How likely is this patch to cause regressions; how much testing does it need?**: It's a small change without doing anything that can change the behavior. The change here is to destroy

### Security Approval Request
* **How easily could an exploit be constructed based on the patch?**: It's not hard to infer when the data race causing an UAF can happen by reading this patch carefully.
* **Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?**: Yes
* **Which older supported branches are affected by this flaw?**: For new Rust backend, it's FF74. For C backend, it exists for a long time.
* **If not all supported branches, which bug introduced the flaw?**: None
* **Do you have backports for the affected branches?**: Yes
* **If not, how different, hard to create, and risky will they be?**: For Rust cubeb backend, this patch can be uplifted to the FF74 easily.
For C cubeb backend, it's easy to import this change from the Rust backend to C backend.

However, the cubeb code are in public github repos. 

- main cubeb repo: https://github.com/kinetiknz/cubeb
- Rust cubeb on Mac OSx: https://github.com/ChunMinChang/cubeb-coreaudio-rs

The update will be submitted in github repos instead of being updated in the gecko directly. I am not sure how to hide the security vulnerability properly when updating the code. (One thing I can do is to update the code without commit messages or comments. The comments can be added in other separated commits anyway.)
* **How likely is this patch to cause regressions; how much testing does it need?**: It's a small change without doing anything that can change the behavior. The change here is to destroy

### Security Approval Request
* **How easily could an exploit be constructed based on the patch?**: It's not hard to infer when the data race causing an UAF can happen by reading this patch carefully.
* **Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?**: Yes
* **Which older supported branches are affected by this flaw?**: For new Rust backend, it's FF74. For C backend, it exists for a long time.
* **If not all supported branches, which bug introduced the flaw?**: None
* **Do you have backports for the affected branches?**: Yes
* **If not, how different, hard to create, and risky will they be?**: For Rust cubeb backend, this patch can be uplifted to the FF74 easily.
For C cubeb backend, it's easy to import this change from the Rust backend to C backend.

However, the cubeb code are in public github repos. 

- main cubeb repo: https://github.com/kinetiknz/cubeb
- Rust cubeb on Mac OSx: https://github.com/ChunMinChang/cubeb-coreaudio-rs

The update will be submitted in github repos instead of being updated in the gecko directly. I am not sure how to hide the security vulnerability properly when updating the code. (One thing I can do is to update the code without commit messages or comments. The comments can be added in other separated commits anyway.)
* **How likely is this patch to cause regressions; how much testing does it need?**: It's a small change without doing anything that can change the behavior. The change here is to destroy the audio stream properly to prevent system callback from being executed after the stream is destroyed.