AXP-Resurection/docs/009-cve-bisect-plan.md

Status: historical. Do not use as execution order. Resume: 009-handoff-20261008.md.

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, 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

• Full CVE = BAD (logo); documented do-not-reflash
• Audit apply log (0 FAIL, many huge offsets)
• Fix applicator abort + keep rejects + offset/fuzz gate
• Stop premature H1 bacon (full-503 halves archived *.full503.bak)
• 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.
• 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.
• H1a (108) — 20260930T075006Z-…-cve-h1a BAD (logo). H1a reproduces; interaction possible; module coherence not yet checked for CVE boots.
• 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.
• 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).
• H1a2a (27) — 20260930T213106Z-…-cve-h1a2a BOOT_OK 2026-09-30T21:36Z (kernel #40). Host kmalloc_caches match. Alone does not reproduce.
• 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.
• H1a2b1 (14) — 20260930T231324Z-…-cve-h1a2b1 BAD (logo). Includes CVE-2022-49980 (udc_lock hypothesis). Set of 14 reproduces.
• H1a2b1a (7) — 20261001T001808Z-…-cve-h1a2b1a BOOT_OK 2026-10-01 (kernel #43). No CVE-2022-49980 in this half.
• 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).
• 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.
• 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).
• 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.