Add advisory for beamr: three classes of silent memory corruption (fixed in 0.16.3)

[tomWhiting]

Filed by the beamr maintainers, per CONTRIBUTING's exemption for
maintainer-filed advisories.

beamr is a BEAM virtual machine with a per-process generational copying
collector. Three classes of defect allowed garbage-collected memory to be read
after it had been relocated or freed. All three are fixed as of 0.16.3.

• as_bytes borrow-across-allocation (fixed 0.16.3) — a helper handed out
  &'static [u8] borrowed from process-heap memory; eleven real crossings,
  nine of them BIF sites reachable from ordinary Erlang/Gleam string and
  binary operations.
• GC refcount-release walk (fixed 0.16.2) — inferred an object's type from
  word[0] and could Arc::from_raw a heap-cons payload.
• ETS stored borrowed caller-heap terms (fixed 0.16.2) that outlived the heap
  they pointed into.

There is no panic or crash in any of these. The vacated region is
zero-filled rather than poisoned, so the failure mode is corrupted or freed
data read as valid.

On the affected range

patched = [">= 0.16.3"] with no unaffected bound, deliberately.

Our own changelog previously said "if you are on 0.16.0 or 0.16.1" — 56
versions are published and it named two. Preparing this advisory is what
caught it. Measured: the file carrying the borrow helper and all five affected
string BIFs is byte-identical — one blob hash — across all 29 tags from
0.4.4 through 0.15.2 and at the 0.16.2 release commit, and the helper's
signature is present from 0.2.0. The introduction points of the two
0.16.2-fixed classes have not been measured, and the advisory says so
rather than implying a narrow range.

Scope note

The advisory text also mentions a separate JIT-reachable rooting class that is
still open and is publicly disclosed in the project's changelog. It is
deliberately not the subject of this advisory — there is no fix to point at
and no configuration a consumer could change in response, so filing it would
add enforcement rather than information. It is mentioned only so that
upgrading to 0.16.3 is not read as a clean bill of health.

Happy to adjust categories, wording, or split this into per-class advisories
if the maintainers prefer.

[djc]

Use the pull request template.

[tomWhiting]

Re-filed as #3122, using the template — apologies for the process miss on this one.

Correcting the record on something this PR body said, since it stands publicly under our name as our position on disclosure. It argued that filing "would add enforcement rather than information." That reasoning was wrong and we withdraw it. A consumer on an affected version running cargo audit today gets a clean result, and that clean result is manufactured by our not having filed — the advisory is the only mechanism by which they learn, so it is information, and withholding it is not restraint.

Two further corrections found while preparing the re-file, both in #3122:

• The date field said 2026-08-07, the day we filed, not the disclosure date. It is now 2026-07-23, the earliest public disclosure of any covered class, with a Disclosure-timeline section in the advisory body naming class 1's separate 2026-07-28 so one field never stands for two dates.
• A reference link pointed at the audit's sweep base rather than at a commit containing the document, and would have 404'd. It is now pinned at a commit that has it, with the sweep base named in prose, since that is where the audit's line coordinates resolve.