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-fortify-bounds-boot-failure-20260927.md

@@ -0,0 +1,87 @@
+# FORTIFY bounds: enlace correcto, arranque fallido
+
+Artefacto remoto: `20260926T223246Z-bisect-ksync-fortify-bounds` bajo
+`/srv/rom/artifacts/009-axp-los23-port/`.
+El dueño informa logo Google, reinicios y finalmente fastboot. El proceso
+de build terminó exit=0 a las 22:32:52 UTC del 26 de septiembre.
+
+## Verificaciones realizadas
+
+- Los dos parches de límites están en las fuentes actuales. Audio/WLAN
+  ya no tienen los símbolos sin resolver `__read_overflow*` en sus objetos
+  LTO. Sí usan `fortify_panic`, que el kernel define y exporta normalmente.
+- `lib/string.c` no tiene modificaciones/stubs; `vmlinux` no contiene los
+  cuatro helpers artificiales de overflow de los intentos anteriores.
+- El boot descargado tiene SHA-256
+  `ba5ac99eb2873dac4c3c8b108753bb89e5aa7a7d71972361e32b39f6ed9ef136`,
+  igual al registro remoto.
+- Desempaquetado local correcto: Android 16, parche 2026-09, header v2.
+  El kernel extraído tiene SHA-256
+  `99348e4f21a46c3bf95dde3a97995cd97375a6792427c5d497b3296fa0c0a906`,
+  idéntico al kernel nuevo y al kernel verificado en el servidor.
+- Los ramdisks en los directorios remotos work/check del fallido y combo4
+  tienen el mismo SHA-256. Se conserva el método ksync.
+
+## Error ignorado por el empaquetador
+
+El log muestra que el último `magiskboot unpack` (línea 91 del script)
+terminó con `Illegal instruction (core dumped)`. El `|| true` permitió
+continuar y declarar DONE. Es un defecto de verificación que debe corregirse.
+No demuestra que la imagen sea inválida: la copia con el mismo hash se ha
+desempaquetado correctamente en el portátil y contiene el kernel esperado.
+No confundir el fallo de la herramienta host con una traza del teléfono.
+
+## Estado de LAB durante esta revisión
+
+ADB disponible como usuario shell, sin privilegios root. LAB ya ejecuta
+combo4, kernel #16, `sys.boot_completed=1`. Pstore vacío. Propiedades de
+motivo de arranque: ro.boot.bootreason=reboot, sys.boot.reason=bootloader.
+No identifican el fallo previo. El tramo de logcat consultado no contiene
+una traza FORTIFY/CFI del intento fallido.
+
+Intentos de leer módulos instalados en vendor devolvieron Permission denied.
+Por tanto, no se ha podido comparar su ABI/CRC con el kernel fallido.
+No se ha ejecutado adb root, cambiado Magisk, reiniciado ni flasheado LAB.
+
+## Prueba adicional de eficacia de wrappers
+
+Se extrajo el bloque FORTIFY del string.h actual a un harness temporal,
+con sus wrappers y macros, tipos auxiliares y libc host. Clang r563880c,
+`-O2 -flto -fuse-ld=lld`. No se añadieron stubs overflow. El handler de
+fortify del harness termina con código 77 para observar el rechazo.
+
+Directorio remoto: `/tmp/axp-fortify-runtime-9t4hrer_`.
+
+13 casos dieron el resultado esperado:
+
+- strlen/strnlen sobre una cadena válida, strcpy válido;
+- memcpy, memmove, memset, memcmp y strncpy: tamaño 8 sobre buffers de 8
+  aceptado, tamaño dinámico 9 rechazado por fortify_panic.
+
+**Límites:** ejecución host x86_64, no kernel ARM64; no prueba CFI del kernel,
+wrappers restantes, todos los call sites, módulos ni arranque. El caso memcmp
+usa el mismo buffer a ambos lados; no es una prueba exhaustiva de comparación.
+Estas pruebas muestran protección efectiva en los casos probados, no que el
+port completo sea correcto.
+
+## Lo que falta para atribuir el fallo
+
+La corrección de límites resolvió el enlace, que era su alcance probado.
+No se ha identificado la instrucción que detiene el arranque. Encontrar
+llamadas a fortify_panic en el binario (incluso en funciones de inicio) es
+normal y no demuestra que se ejecuten durante el fallo.
+
+Prioridad: preparar una captura de fallo utilizable antes del próximo ensayo.
+Comprobar en la referencia funcional el acceso y funcionamiento de pstore/
+ramoops, incluido el mecanismo del dispositivo que procesa sus registros.
+Un arranque de diagnóstico puede instrumentar fortify_panic para registrar
+caller/backtrace conservando su comportamiento de fallo; también debe poder
+distinguir una caída CFI, un watchdog y un fallo de módulos. Esa instrumentación
+sin un canal persistente/serial verificado no garantiza obtener evidencia.
+
+Conservar combo4 como referencia aceptada. No habilitar FORTIFY para ship,
+ni atribuir el fallo a un controlador concreto, ni reintroducir stubs/no-ops
+a partir del solo síntoma del logo. Revisar después compatibilidad de módulos
+y los call sites identificados por una traza real.
+
+Plan de captura (siguiente documento): `docs/009-fortify-diag-capture-plan.md`.