# DF-5135 — VERDICT: reproduced (adjacent-param corruption from bool tunables), fix validated

## Mechanism

* `module_param_named(<bool params>)` in i915_params.c expands through
  moduleparam.h:52-56 to `TUNABLE_bool(name, var)` → moduleparam.h:41 →
  `TUNABLE_INT(..., (int *)&i915_modparams.<bool>)`.
* `bool` = `_Bool` = 1 byte (sys/sys/stdint.h:58; verified on guest:
  `sizeof(bool)=1`). `tunable_int_init` → `kgetenv_int` stores an int
  (4 bytes) at that address when the tunable exists in the kernel env.
* `struct i915_params` (i915_params.h:73-77) keeps all 13 bools at the tail;
  layout verified live: error_capture@110 … enable_dp_mst@114,
  enable_dpcd_backlight@115, enable_gvt@116 (last), sizeof=120.
* Setting any bool tunable therefore rewrites the following up-to-3 bool
  members with the upper bytes of the value (little-endian: value 1 zeroes
  them). The write stays inside the padded struct — contained corruption of
  *other* params (e.g. silently disabling verbose_state_checks, MST, or
  hangcheck-related bools), plus a latent landmine for any future bool param
  whose neighbours are not ≥3 pad bytes.

## Name mangling (discovered during verification)

The shipped `/boot/kernel/i915.ko` registers the macro-generated tunables
under mangled names — `strings` shows `KBUILD_MODNAME.enable_gvt`,
`KBUILD_MODNAME.verbose_state_checks`, `KBUILD_MODNAME.(enable_guc)` (unsafe
params even get parentheses) — because `-DKBUILD_MODNAME="i915"` does not
reach i915_params.c. The explicit `TUNABLE_INT("drm.i915.<name>")` lines in
i915_params.c:43-127 exist precisely to give the INT params sane names; the
bools and the charp paths (no-op `TUNABLE_charp`, moduleparam.h:45 — the
firmware-path params are dead on this port) have none.

## Live run (stock modules)

```
$ strings /boot/kernel/i915.ko | grep '^KBUILD_MODNAME' | head
KBUILD_MODNAME.enable_gvt
KBUILD_MODNAME.verbose_state_checks
...
$ kenv KBUILD_MODNAME.verbose_state_checks=1
KBUILD_MODNAME.verbose_state_checks="1"
$ kldload i915 && kldload ./i915probe.ko && sysctl hw.i915probe.params
(dmesg)
dmabug:   error_capture=1  disable_display=0  verbose_state_checks=1  nuclear_pageflip=0
dmabug:   enable_dp_mst=0 enable_dpcd_backlight=0 enable_gvt=0
```

`enable_dp_mst` default is **true** (i915_params.h:69) — it came back 0
solely because setting the *unrelated* `verbose_state_checks` param stored 4
bytes across offsets 112..115. Baseline without the kenv var: dp_mst=1.

## Fix validation

fix.diff (moduleparam.h: byte-safe TUNABLE_bool), applied to guest /usr/src,
i915.ko force-rebuilt (`rm i915_params.o; make; make install`), rebooted,
identical kenv+load sequence:

```
dmabug:   verbose_state_checks=1  ...
dmabug:   enable_dp_mst=1 enable_dpcd_backlight=0 enable_gvt=0   <-- intact
```

fix_baseline_reproduced=1 (dp_mst 1→0 corruption on stock), 
fix_patched_reproduced=0 (no corruption after fix). fix_status=fixed.

## Impact honesty

Trigger requires root (kenv/loader.conf) — this is a param-integrity /
defense-in-depth defect, not an unprivileged primitive: impact=none beyond
silent misconfiguration of unrelated driver params. Severity Low.

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.