There were multiple issues here:
1. listeners stored in the same key overwriting the previous one
2. missing `use_capture` parameter in `remove_event_listener`/`remove_window_event_listener`
The key used to store the listener function in `listenerMap` was a
javascript `Object`, when used as a key it was thus serialized to
the string `"[object Object]"`, meaning all listeners where effectively
set to the same key when calling `add_event_listener`/`add_window_event_listener`.
Later on when calling `remove_event_listener`/`remove_window_event_listener`,
it then tried to remove the incorrect one or none at all if there was a
mix of the same event name registered on an element or the window.
To fix I implemented a function `listener_key` in the javascript code
which will generate a different key based on the event's:
- `id`: dom element's id or 'window' (when event listener added to the
window)
- `name`: the event name (eg: `click`), each event handler should be
removed for the event name it was register on.
- `data`: we can register events with different data, each one generate
a new listener which has to be removed.
- `callback`: same as `data`, if you register two similar handler but
with two different callback, each one should be removed.
- `useCapture`: this one is a bit tricky, but when you register an event
handler in javascript, if you don't pass `useCapture`, it defaults to `false`.
When you remove an handler, you have to pass the exact same
`useCapture` option you registered it with. In this case, we allowed
to register an event with different `useCapture`, but didn't allow to
pass the `useCapture` when removing it. We always called `removeEventListener`
without the `useCapture` parameter which removed the handler properly
only when it was registered with `useCapture=false`.
I also switched the `WasmMemoryInterface.listenerMap` from `{}`
(javascript object) to a `new Map()`, which is available everywhere
nowadays.
`GetParameter4i` can be used to retrieve the current scissor rect, or
the curent viewport, which was previously impossible.
Also adds `BlendEquationSeparate` which seemed to be missing.
Also removes an instance of `do`.
1. Properly set `id` and `mapping` on the `get_gamepad_state` result
2. Increase `id` limit to 96 bytes, connecting my DualShock 4 made it crash
3. If an `id` or `mapping` is longer than the limits, slice it and add `...`
Switched to a recursive mutex so that procedures which need to perform
lookups can do so while also maintaining the lock across their entire
body in order to guarantee atomicity for each environment operation.
This removes the data race caused by multiple threads using the
unprotected global `random_string_seed`, so long as no two threads share
the same random generator; this is the default case.
Additionally, `os2.random_string` now takes into account the full buffer
slice given to it.
`strings.to_cstring` previously would not check if the buffer could
handle the extra null byte and could lead to segmentation violations
when using the resulting string in an API expecting the terminator.
Adds a directory walker, a method of exposing and retrieving errors from
the existing read directory iterator, allows reusing of the existing
read directory iterator, and adds a file clone procedure
This fixes some vulnerabilities in the resolver that make spoofing DNS
queries somewhat trivial due to the code failing to randomize xid, as
well as match the reply xid with the query, and the origin of the packet:
- xid of the query was fixed at zero
- xid from the reply was never checked
- source address of the reply was never checked
This means anyone can flood the host with a fake reply with xid 0,
guessing the source port is trivial as it's less than 16bits (2^16 -
1024), which would cause odin to resolve a hostname to whatever an
attacker wanted.
While here also plug in two memory leaks.
Since this is CVE material, I've contacted @kelimion before hand which
instructed to put it in a PR.
There are also more bugs as the code conflates answer section,
authority section and aditional section into one, while in reality
only the anwer section should be taken into consideration.
