Esta semana apareció un write-up que me pegó más fuerte de lo que esperaba: un tipo se compró a inicios de 2023 un access point Wi-Fi 7 de TP-Link, el EAP770, y resulta que se lo vendieron antes de que el estándar siquiera estuviera cerrado. El firmware era el último y también el primero que el fabricante publicó, porque el equipo quedó declarado fin de vida sin haber recibido una sola actualización. Todo funcionaba más o menos, hasta que empezó a darse cuenta de que las descargas grandes por Wi-Fi traían bytes corruptos. Y lo peor: venían con checksum TCP válido.
Checksum bueno, datos podridos
Sin embargo, el dato técnico que me quedó pegado: cada segmento dañado tenía 64 bytes malos seguidos, pero con checksum recalculado y correcto. O sea, algo en el camino corrompía el payload y después se la jugaba re-haciendo el checksum para que nadie notara. TCP, que es la capa que confía ciegamente en eso, tragaba completo. Lo que salvó las transferencias fue el nivel de abajo: TLS y SSH reportaban bad record MAC, porque sus MACs end-to-end sí veían la basura.
La raíz era un bug de coherencia de caché en el driver de red de Qualcomm de ese hardware: el driver recicla buffers de paquetes sin invalidar la caché del CPU para el buffer completo antes de devolverlos al NIC, y una línea de caché sucia del paquete anterior se escribía encima del paquete nuevo. Lo irónico de la pega offload: el acelerador de bridging de Qualcomm (SFE/PPE) era el encargado de re-calcular los checksums sobre la basura. Le da velocidad al sistema a cambio de corromper silenciosamente los datos, y además te oculta la traza. Me acuerdo de esas weas de «el acelerador optimizando mi infraestructura» bien: cuando la velocidad viene con checksums falsos, el acelerador es el problema.
El parche existía, pero no para mí
La solución eran dos writes a cero en sysfs para desactivar el offload. El problema: la shell de TP-Link corre como uid 1, sin capacidades, y no hay firmware v1 disponible para flashear nada encima. La única vía que quedaba era entrar por el kernel.
Lo hizo encadenando CVE-2022-0185 (integer underflow en legacy_parse_param(), alcanzable desde un user namespace no privilegiado) con manipulación de pipe buffers para escalar a write arbitrario. Lo impresionante: explotando un CVE de 2022, no un 0-day. O sea, el 0-day no existía, el parche de kernel que solucionaba ese bug ya estaba en kernels upstream hace años, pero el firmware nunca lo levantó. Cada vez que alguien justifica quedarse en un branch viejísimo porque «si funcionaba, no lo toques», se le olvida que el parche que salvó a toda la gente ese CVE no bajó nunca a su versión.
La IA trabajando en 0-days que no le correspondían
Lo más llamativo del write-up: el tipo usó Opus 4.8 para desarrollar el exploit. Es decir, le pidió instrucciones concretas sobre primitivas y sobre el layout de slab, y el modelo le fue iterando el exploit hasta que era estable. Algo que en 2017 le habría tomado meses a un equipo de investigación, hoy se lo saca con una tarde de tokens. La barrera para «hacker de hardware propio» bajó tanto que ya no es una barrera, es un pasacalle.
Lo que más me pegó es el detalle del watcher que corre en su NAS: al AP se le cae el offload desactivado con cada reboot, así que el watcher re-ejecuta el exploit cuando la wea vuelve. Rebootear el AP para volver a rootearlo, indefinidamente, porque el fabricante jamás va a soltar este parche. Un access point de consumidor, en 2026, con su «sysadmin» siendo un exploit de kernel en un cron. Es la definición de mantenimiento a la fuerza bruta.
Lo que me deja
No compro hardware de red sin saber su política de fin de vida. Wi-Fi 7 antes de que el estándar estuviera cerrado fue una head-ache cara. Lo segundo: los aceleradores y offloads de firmware cerrado son una caja negra que corrompe datos y te la cobra en checksums válidos; cuando algo falla de forma inexplicable en el borde de la red, sospecho de ese path antes que de mi TCP stack.
Y por último, aunque suene a queja de tío viejo: cuando compras infraestructura, estás comprando no solo el hardware sino el compromiso del fabricante de mantenerlo. TP-Link se lo vendió como Wi-Fi 7 y lo abandonó con el estándar a medio cerrar. El tipo hizo bien lo que hizo, pero no debería haber tenido que escribir un exploit de kernel para usar el aparato que pagó.
Fuente del tema: Wanted to download an ISO, ended up writing a kernel exploit, del blog de deafbeef.
Fuente de inspiración: Wanted to download an ISO, ended up writing a kernel exploit
