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