Escribió un exploit del kernel para arreglar su propio router WiFi

Quería descargar un ISO de Linux. Terminó escribiendo un exploit del kernel para hackear su propio router. No por diversión, ni por deporte de hackers: porque el fabricante se negó a dejarle arreglar un aparato que él compró y que estaba en su propia casa.

Así se ve cuando el fabricante abandona tu hardware y la única solución es un exploit del kernel.

El router que llegó obsoleto de fábrica

En agosto de 2023, un desarrollador compró un punto de acceso WiFi 7 de TP-Link, el modelo EAP770. Solo había un detalle: el estándar WiFi 7 ni siquiera estaba terminado. Se finalizó en septiembre de 2024, catorce meses después de su compra.

El aparato funcionaba… a medias. Descargas grandes por WiFi se rompían a mitad de camino con errores TLS como bad record mac. Los archivos de unos pocos GiB simplemente no llegaban enteros. Durante años él se convenció de que el problema era rsync, o SSH, o su configuración.

No era su culpa. Era el router.

TP-Link lo declaró obsoleto antes de que él lo usara

Cuando por fin fue a buscar una actualización de firmware, descubrió algo increíble: TP-Link nunca lanzó ni una sola actualización para ese modelo. El firmware que salió de fábrica en 2023 era, literalmente, el único que existió. El sitio solo tenía firmware para la versión 2, con hardware distinto.

Contactó con soporte en junio de 2025. No encontraron la v1 en su base de datos. Le pidieron fotos del aparato y la caja… y luego le confirmaron lo que sospechaba: el EAP770 v1 era un producto fin de vida. Sin parches. Sin soporte. Sin nada. Y lo peor: lo declararon obsoleto antes de que él terminara de desempacarlo.

La lección que él mismo admite: nunca compres hardware antes de que el estándar esté finalizado y certificado. Pero eso no borra lo absurdo de la situación.

Dos ceros que necesitaban permiso de root

Tras investigar durante años, encontró la causa raíz: un bug de coherencia de caché DMA en el driver de Qualcomm (qca-nss-dp). El driver reutiliza buffers de paquetes sin sincronizar la caché del CPU, así que una línea de caché sucia de 64 bytes sobrescribe fragmentos de los paquetes recibidos. El router entrega datos corruptos con checksums válidos: la descarga falla por dentro, pero por fuera se ve perfecta.

La solución eran dos líneas:

echo 0 > /sys/sfe/l2_feature
echo 0 > /sys/sfe/ppe_rfs_feature

Desactivar una aceleración que rompe los datos. Eso era todo. Pero esos archivos solo se pueden escribir como root, y la shell de TP-Link corre como uid 1 sin ningún privilegio. No hay ajuste en la interfaz web. No hay firmware v1 que parchear. TP-Link había bloqueado cada ruta.

Ese es el problema con el que se quedó: conocía el arreglo, tenía el aparato en su casa, y el fabricante no le dejaba aplicarlo.

La solución: un exploit del kernel contra su propio router

Así que hizo lo único que tenía sentido. Con ayuda de una IA (Opus 4.8), montó una cadena de explotación con CVE-2022-0185 —un desbordamiento por underflow entero alcanzable desde un namespace de usuario sin privilegios— combinada con manipulación de pipe-buffers para convertir el desbordamiento en escritura arbitraria.

Construyó un entorno de pruebas en QEMU, afinó la cadena hasta que fue estable, y la ejecutó contra el router real. El objetivo final: sobrescribir modprobe_path para que el kernel ejecutara su script como root global. Le tomó unas 17 horas de trabajo iterativo. Y funcionó.

Consiguió root en su propio punto de acceso, escribió los dos ceros, y las descargas grandes volvieron a funcionar sin corromperse. La única pérdida: un 8% de velocidad al desactivar la aceleración. Prefirió pagar eso a seguir con datos basura.

El detalle que debería preocuparte

Esto no es solo la historia de un desarrollador terco. Al revisar el código del kernel, encontró 13 drivers más en el árbol oficial de Linux con la misma clase de bug. Y aquí viene lo importante: en equipos x86 el hardware mantiene la caché coherente con el DMA, así que el bug no se manifiesta. Pero en ARM y otras arquitecturas no-coherentes, esos drivers corrompen datos en silencio.

Traducción: hay routers, dispositivos IoT y equipos con procesadores ARM que están corrompiendo datos ahora mismo y nadie se ha enterado, porque en tu PC de escritorio con Intel nunca lo verías.

Lo que esto significa para ti

Si tienes un router WiFi 7 barato comprado "antes de tiempo", o un dispositivo ARM que hace transferencias grandes y falla de forma intermitente, el problema puede no ser tu conexión ni tu software. Puede ser exactamente este tipo de bug que el fabricante ni siquiera sabe que existe.

La verdadera lección no es técnica, es de derechos del consumidor: compraste un aparato, es tuyo, y el fabricante lo abandonó sin darte ni una sola actualización. Cuando tú —no la empresa— encuentras la solución, no deberías necesitar un exploit del kernel para aplicarla en tu propia casa.

¿Y tú? ¿Te ha pasado que un fabricante abandonó un producto que seguías usando y te dejó sin soporte? ¿Crees que deberían obligar a las empresas a mantener el firmware de lo que venden por ley? Cuéntalo en los comentarios.

📌 Comparte esto con alguien que todavía crea que su router funciona perfecto — puede estar descargando archivos corruptos sin saberlo.