aarch64: EL1 external DATA_ABORT at exactly end-of-RAM — FAR=0xffff000060000000 ELR in kernel text, ESR=0x96000010 DFSC=0x10, 1/50 SS-gate boots

[ryanbreen]

Face

An EL1 external data abort at exactly the end of QEMU's 512MB RAM window, from an ELR inside
kernel text:

[DATA_ABORT] FAR=0xffff000060000000 ELR=0xffff00004040af94 ESR=0x96000010 DFSC=0x10 TTBR0=0x100004406c000 from_el0=0
[FATAL_REGS] label=DATA_ABORT cpu=3 spsr=0xa00003c5 esr=0x96000010 far=0xffff000060000000 elr=0xffff00004040af94 sp=0xffff000054274f60
  x0=0xffff000054274f30 x1=0xffff000040800008 x2=0x0 x3=0x1
  x4=0x11515c x5=0x0 x6=0x0 x7=0x0
  x8=0x0 x9=0x0 x10=0x50 x11=0x0
  x12=0xffff000040858ad0 x13=0x115165 x14=0x0 x15=0x0
  x16=0x0 x17=0x133c x18=0x0 x19=0x0
  x20=0xffff000040800008 x21=0xffff000054274ff8 x22=0xfff80001f6344698 x23=0xffff000060000000
  x24=0x0 x25=0xffff000040848a00 x26=0xffff000040848000 x27=0xffff00004120a000
  x28=0x4040 x29=0xffff000040848a00 x30=0xffff00004040afa4

Field-exact signature for classification: ESR=0x96000010 (EC=0x25, data abort from same EL),
DFSC=0x10 (synchronous external abort, not a translation/permission/alignment fault — no
software-visible page-table cause), from_el0=0, FAR=0xffff000060000000.

0xffff000060000000 is the HHDM alias of physical 0x60000000 — on a -m 512 QEMU virt machine,
RAM is [0x40000000, 0x60000000), so this FAR is exactly one byte past the last mapped RAM
address, i.e. an off-by-one/end-of-RAM dereference rather than a wild pointer into an arbitrary
unmapped region. ELR=0xffff00004040af94 is inside kernel text (x30=0xffff00004040afa4, ten bytes
later, is very likely the return address of the faulting call, consistent with a load/store at
ELR reading through a pointer built as base + size where base + size == end-of-RAM).

Not #635's family: #635/#576/#626/#633/#637 are all FAR == ELR (a PC transfer to a garbage
resume PC). Here FAR != ELR — this is an ordinary load/store dereferencing a bad data pointer at
a normal-looking kernel PC, not a control-flow transfer to a garbage PC.

Rate

Observed once, in run-aarch64-service-sequence-gate.sh --boots 25 --profile both on
fix/607-576-zero-pc-family @ 175277c7 (T3-G PR2 landing round; this commit range contains only
docs and gate-script changes since the round-2 confirm battery — no kernel source diff):

• This run: 1/50 (-cpu cortex-a72, boot 5; -cpu max 25 boots clean)
• Round-2 confirm battery (clean100 + starved100 both profiles, 450 boots total, fix/607-576-zero-pc-family @ 2a2eeefc): 0/450
• main @ 9602d6d4 baseline (clean100 + starved50, 300 boots): 0/300

1/50 this run, 0/750 prior boots on this branch/baseline pair. Kernel source is identical between
this run and the 450-boot round-2 battery (both built from the same production code; the intervening
commits on 175277c7 are docs + gate scripts only), so this is not attributable to any change in
this PR. Pre-adjudicated at this rare, low observed rate pending more data.

Coordinator ruling R42 (binding)

the new EL1 DATA_ABORT (FAR=0xffff000060000000 = exactly end-of-RAM on the 512MB QEMU virt machine;
ELR=0xffff00004040af94 in kernel text; ESR=0x96000010 DFSC=0x10 synchronous EXTERNAL abort;
from_el0=0; FAR!=ELR so NOT the #635 family) is a rare pre-existing face newly sampled, not
plausibly caused by this round's docs/gate-script-only commits: kernel source is identical to the
450-boot round-2 battery (0 occurrences) and 300 main-baseline boots (0 occurrences). Disposition:
file as its own issue with the preserved serial; pre-adjudicate at the rare observed rate (1/50 this
run, 0/750 prior); add to PR #634's known-faces table; note as a candidate wild/off-by-one-pointer
symptom on the PR3 producer-RCA trail (an end-of-RAM dereference is pointer-corruption-adjacent).
Landing PROCEEDS on the round-2 battery evidence — no re-run.

Serial

Preserved in-repo:
docs/planning/teardown-unification/607-576-serials/round2-gates/ss25-r175277c7-cortexa72-boot5-external-abort-endofram-96000010.txt
(fault record at :5424-5450), with the run's census line and this ruling quoted in
docs/planning/teardown-unification/607-576-serials/README.md under "Landing round — the end-of-RAM
external-abort face".

Disclosed, not part of this face: the same boot also carries an earlier, unrelated,
kernel-recovered fault on a different CPU — [UNHANDLED_EC] cpu=2 EC=0xe ELR=0xffff00004059c2a8 at
:696 (esr=0x3a000000, far=0x0) — which the gate's current classifier does not score and which
this issue does not claim.

Why this belongs on the PR3 producer-RCA trail

#633, #635, #637, and #638 are the working theory of one producer-side corruption family: stale
writes landing tids, addresses, or garbage into stack/context memory that a later consumer (a
resume-PC transfer, a heap free) reads back and faults on. An end-of-RAM dereference — a pointer
that is exactly base + size for the true size of RAM, one past the last valid byte — is the
textbook shape of an off-by-one/wild-pointer computation, and is worth checking against the same
producer trail rather than filing in isolation: if the corrupting write elsewhere in this family
writes a size or count into a slot later read back as a pointer or added to a base address, an
end-of-RAM FAR is exactly what that would produce. Not claimed as the same root cause — flagged as a
candidate data point for whoever RCAs #633/#635/#637/#638's shared producer.

Related: #633, #635, #637, #638, #613 (adjacent field-shape family, all pre-adjudicated at low rates
on the same branch).

[ryanbreen]

Not the resume-PC face, but a shared suspect: a +272/+288 over-read at the top of the last slot (T3-G PR3)

Examined as part of the producer-side RCA for #635/#633/#637. This is not that face: here
FAR != ELR and the ELR is in kernel text, so it is an ordinary data load going wrong, not an
instruction fetch at a bad resume PC. PR-A's consumer narrowing cannot touch it, and no leg in its
battery reproduces it. Keeping it as its own issue.

What the same RCA turned up that is worth attaching here as a lead — offered as a lead, not a
finding:

CpuContext is 288 bytes and Aarch64ExceptionFrame is 272. They share their first 240 bytes
exactly (x0..x30) and diverge after:

offset	CpuContext	Aarch64ExceptionFrame
248	sp	elr
256	sp_el0	spsr
264	elr_el1	(8 bytes of padding)
272	spsr_el1	(past the end)

Reading a frame through a CpuContext pointer therefore reads +272 — and for a frame pushed at
the top of a kernel-stack slot, +272 is past the slot top. The aarch64 heap ends at
0x541F_FFFF and the kernel-stack pool begins at 0x5420_0000, so those two regions are adjacent;
an over-read at the top of the last slot walks off the end of the mapped window, which is the shape
of an external abort at exactly end-of-RAM.

Only x19/x29/x30/sp/elr_el1 on the context side and x16/x30/elr/spsr on the frame side carry
const _: () = assert! offset locks today. sp_el0, spsr_el1, and both struct sizes do not.
Locking every divergent offset plus both sizes would make a 272-vs-288 confusion a compile error
rather than an abort — that belongs to the producer-side PR, and is recorded here so the lead is not
lost.

Same suspect is attached to #639 for a different symptom (a kernel data pointer appearing in a
saved-PSTATE slot).