TP-Link EAP770 : corrompre les données Wi-Fi sans patch, écrire un exploit noyau
Sommaire
En bref
- Un utilisateur découvre que son point d'accès Wi-Fi 7 TP-Link EAP770 corrompt les téléchargements volumineux en raison d'un bug d'accélération matérielle (SFE/PPE) côté Qualcomm.
- Le correctif, écrire deux zéros dans sysfs, nécessite l'accès root, impossible via SSH limité à uid 1.
- Face à l'absence de mises à jour (produit EOL depuis août 2023, un mois après achat) et à l'impossibilité de flasher une ROM, il écrit un exploit noyau pour corriger sa propre infrastructure.
- La corruption affecte les connexions LAN-vers-Wi-Fi à débit élevé, laissant TCP recevoir des segments valides mais corruptus, détectables uniquement par la couche applicative (TLS).
Ce que dit la source
L'auteur rapporte que son TP-Link EAP770 v1 (Qualcomm IPQ9574, Linux 5.4.164, firmware 1.0.0) corrompt les transferts de fichiers larges (plusieurs GiB) sur Wi-Fi, avec des erreurs TLS « bad record mac » et des segments TCP affichant 64 octets consécutifs corrompus mais des checksums valides. La cause est identifiée dans le moteur d'accélération SFE/PPE du SoC Qualcomm, qui recalcule les checksums TCP après avoir déjà corrompu les données. Le produit est déclaré fin de vie par TP-Link en juin 2024, sans mises à jour disponibles pour la v1. TP-Link a commercialisé ce matériel avant la finalisation du standard Wi-Fi 7 (septembre 2024) et sans certification Wi-Fi Alliance.
- Le bug n'apparaît qu'avec plusieurs flux TCP simultanés en direction Wi-Fi ; les tests filaires et UDP ne montrent aucune corruption, isolant le problème au pont Ethernet-Wi-Fi.
- La corruption forme des blocs de 64 octets (taille d'une ligne de cache ARM), signalant un problème de cohérence de cache ou DMA plutôt qu'une erreur bit aléatoire.
- Le correctif théorique, désactiver SFE/PPE avec `echo 0 > /sys/sfe/l2_feature` et `echo 0 > /sys/sfe/ppe_rfs_feature`, n'est accessible qu'en root, mais le shell SSH de TP-Link fonctionne en uid 1 sans capabilities.
- Wirelessly relayd traffic via WireGuard masque complètement le problème, car les paquets perdus sur l'authentification AEAD forcent TCP à retransmettre les données incorruptibles, sans exposer le défaut du pont.
- Pas de ROM v1 pour patcher et flasher directement ; l'image EAP773 est rejetée, les versions v2 sont chiffrées, le flashage du chipset demande une sonde JTAG.
Dans les commentaires
Débat partagé : le fil valide la rigueur de la démarche technique et critique le manque de support TP-Link, mais reste divisé sur la proportionnalité de la réponse. Quelques commentateurs contestent l'acceptabilité d'avoir gardé un appareil visiblement défectueux dès août 2023 sans le retourner immédiatement. Des retours convergents soulignent les failles systémiques du logiciel embarqué chez les constructeurs réseau grand public.
- Plusieurs commentaires critiquent l'auteur pour ne pas avoir retourné l'appareil dès 2023 quand la corruption était claire, estimant qu'accepter un produit défectueux renforce l'inertie de TP-Link et pénalise les autres consommateurs.
- Un récit parallèle d'un autre contributeur décrit un bug similaire dans l'ONT Airoha d'un opérateur américain, avec reverse engineering et live patching assistés par IA, confirmant que ces défauts de cache cohérence sont récurrents chez les vendors SoC.
- L'absence de procédure pour obtenir la v1 du firmware (TP-Link l'a « perdue ») suscite des questions sur la gestion basique des archives produit et sur la crédibilité du support.
- Un utilisateur GL.inet est mis en contraste positif : support réactif par email, diagnostic proactif, accès SSH root par défaut, présenté comme l'exception plutôt que la norme.
- Plusieurs mentionnent OpenWrt comme solution préférable dès le départ pour les APs : lotterie du matériel constructeur vs. stack logiciel stable et maintenable.
- Une remarque technique sur l'API DMA noyau : l'auteur aurait pu disposer d'options de flush cache ou de mappages plus cohérents sans code spécifique à l'architecture, mais c'est une critique modérée plutôt qu'une contestation majeure.
Alternatives citées : GL.inet (Flint 3 cité comme alternative avec meilleur support et SSH root natif) ; OpenWrt (mentionné plusieurs fois comme approche préférable) ; références à Airoha/Astra pour debugging assisté par IA sur matériel similaire.
Notre lecture
Article technique solide qui expose un défaut d'infrastructure matérielle réel et non trivial à diagnostiquer. Le choix d'un Wi-Fi 7 non certifié en août 2023 relève effectivement de l'imprudence affichée par l'auteur lui-même. En revanche, la passivité de TP-Link (pas d'update pendant 18 mois, produit introuvable dans sa propre base de données, support inaccessible) et l'absence de pivot rapide vers une alternative en 2024 illustrent une tolérance aux défauts d'expérience utilisateur. L'exploit noyau écrit pour contourner le shell restreint est un symptôme du problème (sécurité par dénuement), pas une solution générale. Pour un DSI ou un responsable réseau, la leçon pertinente est simple : le matériel grand public TP-Link sur protocoles émergeants reste hautement risqué, OpenWrt (quand supporté) change le calcul coûts-bénéfices, et les bugs DMA/cache cohérence dans les SoCs Qualcomm embarqués méritent une vigilance accrue en production. Intéressant techniquement et à suivre comme tendance sur la fiabilité Wi-Fi 7, mais pas d'action immédiate identifiable hors du segment réseau TP-Link lui-même.