From a4fb1deff3afcb05bb78ad05b448e10b9a5fefb1 Mon Sep 17 00:00:00 2001 From: Simon Dick Date: Wed, 16 Sep 2026 19:59:41 +0100 Subject: [PATCH] Add the missing changelog entry for #84 PR #84 widened the heap detectors to four more allocators but never got a changelog entry. It is user-visible twice over: more of the guest's memory is guarded, and real PhxAss stops being silent under --sanitize because the new coverage found a genuine two-byte over-read of its own timerequest. Anyone running the corpus sweep needs to know that one report is expected rather than a regression. Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_01AKBJRT9j5APTyKyZtj8f23 --- userdocs/Changelog.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/userdocs/Changelog.md b/userdocs/Changelog.md index c9a8626..98808db 100644 --- a/userdocs/Changelog.md +++ b/userdocs/Changelog.md @@ -5,6 +5,28 @@ version scheme in `Cargo.toml`. ## Unreleased +- **The heap detectors now cover four more allocators** (issue #83, + tier 0): `utility.library`'s `AllocateTagItems`, `dos.library`'s + `AllocDosObject`, and `exec.library`'s `CreateIORequest` and + `CreateMsgPort`, plus their matching free calls. All four carve from + the same guest heap as `AllocMem`, so redzone *space* was already + being reserved for them whenever `--sanitize` was on — only the + shadow marking was missing, which meant a guest overrunning a + `FileInfoBlock`, an `RDArgs`, a `MsgPort` or a `TagItem` array that + volamos handed it went unreported. + + It found a real bug on the first sweep: the PhxAss assembler asks + `CreateIORequest` for 40 bytes (`sizeof(struct timerequest)`) and then + reads two bytes one past the end. Harmless on real hardware, where + that read lands in whatever follows on the heap, which is exactly the + class of latent bug this exists to surface. So **PhxAss is no longer + silent under `--sanitize`** — that one report is expected; + `--sanitize-ignore-pc` silences it if you want a clean baseline. + + Still not covered: `exec.library/Allocate`, where the guest owns the + memory pool, and which is where a C runtime's `malloc` actually + sub-allocates. + - **Diagnostics now name the source location** (issue #74). Sanitizer violations are annotated with `file:line` when the program carries a `HUNK_DEBUG` `LINE` block (SAS/C's `DEBUG=LINE`, PhxAss's