`end` < `start`, which always [leads to](https://searchfox.org/mozilla-central/rev/f6776253b65c05351b4004fe7c3353cac8d8a4af/dom/media/webaudio/OscillatorNode.cpp#315) a very large `aSize` for a write controlled by content. The loop on this (audio rendering) thread will eventually seg fault before exiting. If the OS has a guard page at the high address end of the stack, then I don't see a way for stacks of other threads to be corrupted.
Bug 1871838 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
`end` < `start`, which always [leads to](https://searchfox.org/mozilla-central/rev/f6776253b65c05351b4004fe7c3353cac8d8a4af/dom/media/webaudio/OscillatorNode.cpp#315) a very large `aSize` for a write controlled by content. The loop on this (audio rendering) thread will eventually seg fault before exiting. If the OS has a guard page at the high address end of the stack, then I don't see a way for memory accessed by other threads to be corrupted.
`end` < `start`, which always [leads to](https://searchfox.org/mozilla-central/rev/f6776253b65c05351b4004fe7c3353cac8d8a4af/dom/media/webaudio/OscillatorNode.cpp#315) 2^32 - 126 <= `aSize` < 2^32, for a write controlled by content. The loop on this (audio rendering) thread will eventually seg fault before exiting. If the OS has a guard page at the high address end of the stack, then I don't see a way for memory accessed by other threads to be corrupted. This thread does not perform nested event loops and so the stack should not grow large, even in unoptimized builds [without](https://searchfox.org/mozilla-central/rev/6321fb8f7533456a62dfa2aa68ee0477a6c8f693/xpcom/threads/nsIThreadManager.idl#54-55) a stack limit.