> **Status: historical.** Do not use as execution order. Resume: [`009-handoff-20261008.md`](009-handoff-20261008.md). # FORTIFY: auditoría del build 20260926T183144Z Revisión de solo lectura en rom-dev01. Sin compilaciones ni flasheos nuevos. El dueño confirma arranque de ksync-slab y fallo del último FORTIFY. ## Artefactos y empaquetado Raíz remota: `/srv/rom/artifacts/009-axp-los23-port/`. - Referencia: `20260926T171215Z-bisect-ksync-slab-only`. - Fallido: `20260926T183144Z-bisect-ksync-fortify-only/boot-make.img`. - SHA-256 registrado del fallido: `89734e6a34f99bfdc2d334e06e1ff49da46dac311139b7dc54f25ae7af0f0641`. - Ambos ramdisks desempaquetados tienen SHA-256 `c9ebabdcec875c896530214c5f2988e30a6bc37754855e4cba4863692d7db519`. - Ambos DTB tienen SHA-256 `2fca15709ff6d9f48fea938952439e8d00c2b998c73e7a216172ae3965b07566`. - El header del FORTIFY conserva Android 16 y parche `2026-09`. - El script usa breakfast y exige TARGET_RELEASE=bp4a. El problema anterior de cambiar la release/ramdisk no aparece en esta comparación. La config embebida del fallido tiene FORTIFY=y, SLAB_FREELIST_HARDENED=n; la referencia slab tiene las dos opciones al revés. Ambos conservan LTO y CFI. ## Hallazgo principal: la exclusión de Clang es ineficaz En `/srv/rom/src/lineage/kernel/google/msm-4.14/security/Kconfig:190-195`: ```text config FORTIFY_SOURCE bool "Harden common str/mem functions against buffer overflows" depends on ARCH_HAS_FORTIFY_SOURCE # https://bugs.llvm.org/show_bug.cgi?id=50322 # https://bugs.llvm.org/show_bug.cgi?id=41459 depends on !CC_IS_CLANG ``` `git grep` no encuentra una definición de `CC_IS_CLANG` en ese árbol. La config generada tampoco contiene CONFIG_CC_IS_CLANG. La restricción usa un símbolo no definido y por ello no detecta el compilador real. `obj/KERNEL_OBJ/include/generated/compile.h` identifica **Clang 21.0.0, r563880c, LLD 21**, no GCC. El commit que introdujo la restricción es `eb4c4383950d`, «fortify: Explicitly disable Clang support». Esto demuestra un defecto de integración/configuración. No demuestra por sí solo la instrucción concreta que provoca el fallo de arranque. Un Clang más nuevo no sustituye automáticamente las adaptaciones del código FORTIFY. Referencia primaria de las adaptaciones upstream: Kees Cook, [fortify: Add Clang support, v7 8/8](https://lists.openwall.net/linux-kernel/2022/02/08/1547). La serie adapta wrappers y atributos de tamaño de objeto; no consiste en añadir cuerpos BUG a símbolos sin resolver. El parche AXP `0008-Graphene-Kernel_Hardening-fortify/4.14/0004.patch`, inspeccionado, añade comprobaciones intra-object; no aporta por sí solo ese soporte Clang. ## Segundo defecto: el error de enlace se convirtió en código ejecutable Primer intento, log remoto `/srv/rom/artifacts/detach-009-bisect-ksync-fortify-20260926T172516Z.log`: ```text ERROR: "__read_overflow2" [techpack/audio/dsp/q6_dlkm.lto.ko] undefined! ERROR: "__read_overflow" [drivers/staging/qcacld-3.0/wlan.lto.ko] undefined! ``` El script `scripts/009-bisect-ksync-one.sh` añade después a `lib/string.c` cuatro funciones exportadas (`__read_overflow`, `__read_overflow2`, `__read_overflow3`, `__write_overflow`) con cuerpo `BUG()`. Así consigue enlazar, pero no resuelve por qué el compilador emite llamadas a esos helpers, declarados para diagnóstico en `include/linux/string.h:241`. El objeto generado `techpack/audio/dsp/q6_dlkm.ko`, desensamblado, contiene: ```text rtac_remove_voice + 0x1d0, offset 0x673ec: R_AARCH64_CALL26 __read_overflow2 ``` El código asociado incluye la copia de elementos en `shift_voice_devices` (`techpack/audio/dsp/rtac.c:638-644`). Falta resolver si el diagnóstico indica un acceso real fuera de límites o un problema de los wrappers/compilador. No convertirlo en un no-op ni aceptar BUG como solución. **Límite importante:** el ensayo despliega solo boot y conserva los módulos vendor previos. Esta llamada existe en el módulo recién compilado, pero no se ha demostrado que ese módulo se cargue en LAB. Tampoco se encontraron llamadas directas desde funciones ordinarias de vmlinux a los cuatro stubs en la búsqueda realizada (sí sus entradas CFI y sus bucles internos). Por tanto, no se atribuye el fallo de arranque específicamente a ese stub. Las llamadas normales a `fortify_panic` son parte de FORTIFY y su presencia no prueba que ninguna se ejecute durante el arranque fallido. ## Siguiente paso justificado 1. Conservar ksync-slab como referencia que arranca. No encadenar más opciones sobre el build FORTIFY fallido. 2. Tratar FORTIFY como un port con dependencias: estudiar la implementación AXP y adaptar soporte Clang al kernel 4.14, incluyendo detección de compilador y pruebas de los wrappers. Corregir la detección sola bloquearía esta opción; no equivaldría a implementar FORTIFY. 3. Retirar los stubs BUG de la receta candidata y resolver los diagnósticos de audio/WLAN, validando la causa de cada llamada. Mantener LTO/CFI como referencia; desactivarlos globalmente introduce otra variable y pierde protecciones ya funcionales. 4. Archivar .config, diff, vmlinux y Module.symvers por build. Comprobar compatibilidad con los módulos realmente desplegados, no solo uname. 5. Obtener una traza del intento fallido que distinga FORTIFY, CFI, carga de módulos y montaje de datos. En esta revisión ADB no detecta teléfonos, por lo que no se han leído registros actuales de LAB. Conclusión: hay un defecto concreto de habilitación y un arreglo de enlace inadecuado. La causa exacta en ejecución sigue pendiente; no anunciar otro boot como reparado únicamente porque vuelva a compilar. Plan de port (siguiente documento): `docs/009-fortify-clang-port.md`. ## Logs LAB post-fallo (2026-09-26, Cursor) Teléfono en fastboot tras FORTIFY. Reflasheo slab-only (`boot_a`/`boot_b`) y reboot. `/sys/fs/pstore/` vacío (0 ficheros); sin `console-ramoops` ni `last_kmsg`. Misma ausencia de traza que en hangs Stage1/CVE previos. No hay dmesg del intento fallido. Artefacto local vacío: `.local-artifacts/009-fortify-crash-20260926/`.