009: Magisk ship pack through US-S5-1 + US-S4 OpenSSH/Jelly/Gallery2.

Release-keys/AVB, CVE clean+hi batches, Yama/slabrand, Pro branding,
bundled apps, and AXP-class product surface docs/scripts.

docs/009-cve-bisect-plan.md

@@ -0,0 +1,171 @@
+# 009 CVE bisect plan (after full CVE Google-logo hang)
+
+**Baseline GOOD:** Stage1 + combo4 + Clang FORTIFY  
+Artifact: `20260929T123401Z-axp-stage1-combo4` (LAB recovered 2026-09-29 via
+`fastboot flash boot` of that pack’s Magisk `boot.img`).
+
+**BAD:** Stage1+combo4+FORTIFY + full `cve-strict.list` (503)  
+Artifact: `20260929T181525Z-axp-stage1-combo4-cve` — compiles, wlan CRC OK,
+**hangs at Google logo**. **Do not** re-flash the full 503 set.
+
+## Audit before more flashes (2026-09-29 evening)
+
+Owner review correctly flagged the applicator and asked for reject/partial
+review **before** bisect flashes.
+
+| Check | Result |
+|-------|--------|
+| Patch `FAIL` count on BAD build | **0** (`OK=503`) — no `.rej` from that run |
+| Continue-on-fail + delete `.rej` | **Procedural defect** (fixed in `apply_cve_strict.sh`) — would hide incomplete applies on future drift |
+| GNU patch “Succeeded with fuzz≥2” | **0** |
+| Hunks with **\|offset\| ≥ 200 lines** | **168** of 503 — strong mis-apply risk even when `patch` exits 0 |
+| \|offset\| ≥ 200 list | `cve-high-offset-ge200.txt` (**73 unique** paths in report extract; full 168 in host fuzz report) |
+| Host report | `/srv/rom/artifacts/009-axp-los23-port/cve-stage/apply-cve-strict-20260929T173037Z-fuzz-report.txt` |
+
+Logo hang alone does **not** identify a CVE id; “Additional Setup” is unrelated.
+USB loss after sideload does **not** mean the zip was not installed.
+
+### Applicator fix (`apply_cve_strict.sh`)
+
+- Default: **abort** on first FAIL (no partial tree).
+- Keep `*.rej` / `*.orig` under `CVE_REJECT_DIR` (no silent delete).
+- **QUALITY_FAIL** if fuzz ≥ `CVE_MAX_FUZZ` (default 1) or
+  \|offset\| ≥ `CVE_MAX_ABS_OFFSET` (default **200**).
+- Forensic only: `CVE_STRICT_CONTINUE=1`.
+
+H1 bacon (`009-bacon-cve-h1`) **stopped** — do not flash that half until a
+strict re-apply (offsets gated) produces a clean tree.
+
+## Next method (revised)
+
+1. Build allowlist = `cve-strict.list` **minus** high-offset (≥200) suspects
+   (and existing denylist).
+2. Re-apply with new applicator (must finish with QUALITY_FAIL=0 / abort).
+3. Bacon that “clean-offset” set → LAB boot test (**fastboot flash boot** only;
+   recover with Stage1 boot if needed).
+4. If still BAD → classic binary bisect on the **clean** list only.
+5. Separately, quarantine high-offset patches for manual review / port
+   (do not bulk-apply with huge offsets).
+
+## Flash rules (LAB)
+
+1. sunfish recovery is in `boot` — bad kernel ⇒ Recovery looks like logo loop.
+2. Unbrick: `fastboot -s 11231JEC207477 flash boot <GOOD boot.img>` → reboot.
+   **Always** pin LAB serial. Never flash “any” fastboot device (GOLDEN risk).
+3. No reboot-loop automation. No unscoped recover watchers.
+4. One reboot after a deliberate flash.
+
+## Diagnostic limits (owner review 2026-09-30)
+
+- A BAD half **reproduces** the hang; it does **not** prove a single CVE is the
+  root cause (interactions / order / mis-apply semantics still possible).
+- Applicator had **0 FAIL** on the original full set; abort/offset gates were
+  still required, but they did **not** clear this logo hang.
+- Bisect flashes are **`boot.img` only** on `boot_a` (serial-pinned). No slot /
+  download / flash miss seen on H1a2: hang tracks what H1a2 changes vs Stage1
+  base. **No** demonstrated need to re-sideload full zip or wipe data for this
+  bisect.
+- “CRC wlan OK” so far = host-side `kmalloc_caches` only (kernel
+  `Module.symvers` vs pack `wlan.ko`). Does **not** check all symbols nor the
+  on-device installed module (adb pull denied without root). Narrows one
+  suspicion; does **not** rule out module ABI skew.
+- Next interpretation: if H1a2a boots, still test H1a2b. If **both** boot alone
+  but H1a2 fails → interaction/dependency, not a single-patch proof.
+- **Applicability (owner 2026-10-01):** AXP A15 success ≠ correct port to
+  LOS23/A16 sunfish. Per [kernel CVE process](https://cdn.kernel.org/doc/html/latest/process/cve.html),
+  each CVE must be judged for *this* tree/config/modules — not bulk-trusted.
+  H1a2b includes useful fixes (USB gadget UAF, QC audio DSP bounds, F2FS
+  state, QRTR) but also arch/drivers off in our defconfig (x86/AMD, s390,
+  CAN/ATA/SAS/kprobes/brcmfmac, …). These are mostly **bugfixes**, not
+  transversal hardening like FORTIFY/allocator. Concrete hypothesis (unproven):
+  `CVE-2022-49980` (`udc_lock` on gadget events) — check whether this tree
+  already holds that lock on the same paths (possible deadlock). Also re-audit
+  F2FS patches vs exact sunfish F2FS version/deps. **In H1a2b1b list**
+  (not H1a2b1a).
+
+### Code review: CVE-2022-49980 vs msm-4.14 (2026-10-01)
+
+Patch only wraps `udc->driver` read in `usb_udc_uevent()` with
+`mutex_lock(&udc_lock)`. On **our** `msm-4.14` `udc/core.c` (base
+`28f9290ae067`, pre-CVE apply), `kobject_uevent()` is still invoked **while
+holding `udc_lock`**:
+
+- `usb_gadget_remove_driver()` → `KOBJ_CHANGE` (called from
+  `usb_del_gadget_udc` / `usb_gadget_unregister_driver` under lock)
+- `udc_bind_to_driver()` → `KOBJ_CHANGE` (called from
+  `usb_gadget_probe_driver` under lock)
+
+`dev_uevent` / `class->dev_uevent` run **synchronously** inside
+`kobject_uevent`. `udc_lock` is a non-recursive `mutex`. Applying 49980 alone
+⇒ same thread: lock → uevent → `usb_udc_uevent` → lock again ⇒ **deadlock**.
+
+This matches community reports that backporting CVE-2022-49980 to older trees
+(e.g. 5.10.y) introduces deadlock; mainline later needed **lock-scope**
+changes (unbind/bind outside `udc_lock`), not the one-liner alone.
+
+sunfish_defconfig: `CONFIG_USB_GADGET=y`, rich `CONFIG_USB_CONFIGFS_*` (ADB /
+MTP / etc.) — gadget bind/unbind at boot is plausible. Still **hypothesis**
+until H1a2b1b (or a 49980-only build) is LAB-tested; do **not** ship 49980
+without the companion lock-order fix (or omit it from the allowlist).
+
+**2026-10-01 evening:** 49980-only LAB = BAD (logo). Deadlock paths on this
+tree include both (a) `device_add` / uevent under `udc_lock` at UDC register
+and (b) `kobject_uevent` from remove/bind while lock held. Serial console /
+pstore stack not captured yet — would confirm hang site; denylist stands.
+
+## GPS
+
+FR-018: no location lockdown.
+
+## Status
+
+- [x] Full CVE = BAD (logo); documented do-not-reflash
+- [x] Audit apply log (0 FAIL, many huge offsets)
+- [x] Fix applicator abort + keep rejects + offset/fuzz gate
+- [x] Stop premature H1 bacon (full-503 halves archived `*.full503.bak`)
+- [x] Clean-offset allowlist bacon + LAB boot
+      Artifact `20260929T203844Z-axp-stage1-combo4-cve-clean` (430 patches,
+      QUALITY_FAIL=0) — **BAD** 2026-09-29T20:42Z: `fastboot flash boot`
+      OK on `boot_a`, then Google-logo hang / USB dark (~4+ min). Recover =
+      Stage1 `20260929T123401Z-axp-stage1-combo4` boot only.
+- [x] Clean H1 (215) bacon + LAB boot — artifact
+      `20260929T213532Z-axp-stage1-combo4-cve-h1` — **BAD** 2026-09-30
+      (logo). H1 **reproduces**; H2 untested; not a single-CVE ID yet.
+- [x] H1a (108) — `20260930T075006Z-…-cve-h1a` **BAD** (logo). H1a
+      **reproduces**; interaction possible; module coherence not yet checked
+      for CVE boots.
+- [x] H1a1 (54) — `20260930T084048Z-…-cve-h1a1` **BOOT_OK** 2026-09-30T19:21Z
+      (kernel `#38`, slot `_a`). Build-tree `wlan`/`kmalloc_caches` CRC
+      `0xe7ccd971` matches Stage1 Gate G (device pull of `wlan.ko` denied
+      without root; intra-pack CRC OK). H1a1 set alone does **not** reproduce
+      the hang.
+- [x] H1a2 (54) — `20260930T200752Z-…-cve-h1a2` **BAD** (owner: Google logo
+      after flash; reproduces). H1a1 GOOD + H1a2 BAD ⇒ hang associated with
+      H1a2 set (still not a single id; module CRC intra-pack was Stage1-class
+      on prior boots).
+- [x] H1a2a (27) — `20260930T213106Z-…-cve-h1a2a` **BOOT_OK** 2026-09-30T21:36Z
+      (kernel `#40`). Host `kmalloc_caches` match. Alone does **not** reproduce.
+- [x] H1a2b (27) — `20260930T222148Z-…-cve-h1a2b` **BAD** (logo alone).
+      H1a2a GOOD + H1a2b BAD ⇒ hang associated with H1a2b set (not proven
+      single patch). Note: owner phrasing “combi” = this half failed on LAB;
+      interaction check already satisfied by testing halves separately.
+- [x] H1a2b1 (14) — `20260930T231324Z-…-cve-h1a2b1` **BAD** (logo). Includes
+      `CVE-2022-49980` (udc_lock hypothesis). Set of 14 reproduces.
+- [x] H1a2b1a (7) — `20261001T001808Z-…-cve-h1a2b1a` **BOOT_OK** 2026-10-01
+      (kernel `#43`). No `CVE-2022-49980` in this half.
+- [x] H1a2b1b (7, includes `CVE-2022-49980`) —
+      `20261001T010705Z-…-cve-h1a2b1b` **BAD** 2026-10-01 (logo). H1a2b1a
+      GOOD + H1a2b1b BAD ⇒ hang associated with this 7-set (49980 still
+      unproven alone).
+- [x] **49980-only** — `20261001T160836Z-…-cve-49980-only` **BAD** 2026-10-01
+      (logo). Single-patch reproduce on LAB. Added to `cve-denylist.txt`.
+      Do not re-apply without lock-scope companion fix.
+- [x] H1a2b1b **without** 49980 (6) —
+      `20261001T170442Z-…-cve-h1a2b1b-no49980` **BOOT_OK** 2026-10-01
+      (kernel `#46`, LAB `11231JEC207477`). Confirms 49980 was the **sole**
+      hang trigger in the H1a2b→…→H1a2b1b BAD lineage (other six alone OK).
+- [x] Clean-offset **minus 49980** (429) —
+      `20261001T180955Z-axp-stage1-combo4-cve-clean` **BOOT_OK** 2026-10-01
+      (kernel `#47`). List md5 `e05056f6…`; apply OK=429. Prior BAD 430 pack
+      `20260929T203844Z-…` kept. **49980 was the only logo hang** found in the
+      clean-offset set so far. 15m poll loop stopped after flash.