## DF-0876 — panic signature

**No kernel panic observed** on the default INVARIANTS-ON GENERIC kernel for
the in-kernel manifestation of this bug in the test environment.

The OOB read of 65503 bytes past the 64-byte `struct ext2_gd` happens
deterministically — `ext2_gd_csum_verify` always runs the read at mount —
but in the test slab layout the read walks through adjacent *mapped* slab
pages (no page boundary is crossed), so no page-fault occurs. The read is
silent and the only observable signature is the csum mismatch in dmesg:

```
WARNING: mount of vn0 denied due bad gd=0 csum=0x8300, expected=0x4e72 - run fsck
```

The `expected=` value is a 16-bit summary of the 65503 bytes the kernel
*actually read* (32 bytes from the legitimate GD + 65471 bytes leaked from
adjacent heap). Across mounts with perturbed heap state, the value varies
(0xcc5e / 0x3a24 / 0xb94 / 0x3d5b / 0x4e72 / 0x72a observed) — proving the
read incorporates varying adjacent heap content. This is the info-leak
manifestation.

The C harness `harness.c` reproduces the page-faulting manifestation
deterministically: it places a 64-byte GD at the end of a page with the
following page PROT_NONE, then runs the verbatim `ext2_gd_csum` loop with
`desc_size=0xFFFF`. The SIGSEGV fires at the predicted address:

```
[D] Invoking ext2_gd_csum_faulting (full ext2_csum.c:684-686 read):
    GD at 0x800473fc0 (end of page 1); next page PROT_NONE at 0x800474000
    Expecting SIGSEGV at 0x800474000 (= gd+64 = start of PROT_NONE page).

[!] SIGSEGV caught during csum read at addr 0x0000000800474000
HARNESS_RC=133
```

That matches what the kernel would do if the slab layout placed the
`e2fs_gd` allocation against an unmapped page (which is heap-layout-dependent
and not reliably controllable from an unprivileged trigger).