# 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.