TypeScript shim: record notifier can be called after the host dropped it

[sargunv-bot]

Where

bindings/typescript/host-support/src/mln_abi.c, mln_abi_queue_push.

What

The notifier and its user data are read under the queue lock, then called
outside it:

    notify = owner->notify;
    notify_data = owner->notify_data;
  }
  mln_abi_queue_release();
  ...
  /* Outside the lock: the notifier reaches the host's runtime, which must not
   * be able to deadlock against a producer. */
  if (notify != NULL) {
    notify(notify_data);

Calling outside the lock is deliberate and correct — a notifier reaches the
host's runtime and must not be able to deadlock against a producer. The gap is
that nothing keeps notify_data alive across that window.

A host that stops notifications between the read and the call drops the state
notify_data points at while a producer is about to dereference it. On the
Node-API transport that state is a boxed threadsafe function; the window is
small but a producer thread is MapLibre's, not the host's, so nothing
serialises them.

Impact

Use-after-free reachable from ordinary teardown: clearing a callback, closing
a Maplibre context, or a worker exiting while MapLibre is still delivering.

Not observed in the suite — found by reading during the owner-token work
(#PR). It predates that change and has the same shape now, per owner rather
than process-global.

Scope

TypeScript only. This queue lives in the TypeScript host-support shim; the
shared src/c_api/callback_adapter.cpp has no equivalent notifier, so Dart and
the other bindings that use the C API directly are unaffected.

Fixing it

Needs the notifier to outlive the call — refcount the registration and release
it after notify returns, or hold a grace period on stop that waits for
in-flight pushes. Out of scope for the change that found it.

[sargunv-bot]

Correcting the framing: this is not pre-existing. The branch that introduced
this report also introduced the TypeScript binding, mln_abi.c included, so
this is a defect that branch would ship rather than one it inherits.

Being fixed on that branch instead of deferred. Will close when it lands.

[sargunv-bot]

Fixed on the branch, in 826dc84 (#553).

The support layer now counts the notifier calls each owner has begun and finished. Replacing a notifier or destroying an owner waits for the calls that began before it, so the host can only release what the notifier reads once no producer can still be inside it. Two monotonic counts rather than one in-flight count, because a steady stream of records would hold an in-flight count above zero forever and never let the waiter go. The wait takes the queue lock the producer has already dropped, so it cannot deadlock against the thread that produced the record.

destroy_callback_owner drops the box too — a host that destroys an owner without stopping notifications first is still done with it, and leaving the entry in the list kept it alive for a process that never asks about that owner again.

Proved by mise run //bindings/typescript:test:notifier-lifetime, which builds the shim under ASan with a hook that widens the window so the race lands on every run. It passes with the wait and reports the use-after-free without it.