ISOダウンロードがきっかけでカーネルexploitを書いた話
原題: Wanted to download an ISO, ended up writing a kernel exploit
なぜ重要か
EOL端末のソフトウェアサポート打ち切りがユーザーにカーネルexploit自作を迫る事態は、IoT機器のライフサイクル問題を象徴する事例として注目に値する。
セキュリティ研究者のdfb氏は2023年8月に購入したTP-Link EAP770 v1がWi-Fi経由の大容量ファイル転送を破壊するバグを発見。メーカーはファームウェア更新を一切提供しないままEOL（サポート終了）を宣言したため、氏は自身のアクセスポイントに対してLinux 5.4.164のカーネルexploitを自作し、sysfsに2つのゼロを書き込むことで問題を解決した。
2023年8月、dfb氏はWi-Fi 7対応アクセスポイントTP-Link EAP770(EU) v1.0を購入した。数GiB以上のファイル転送が頻繁に失敗し、SSHはMAC（メッセージ認証コード）エラーを報告。rsyncやSSHの設定を変えても改善せず、Wiresharkでも不正なチェックサムやパケット再送は確認できなかった。
その後Tailscaleを経由するとWireGuardの暗号化トンネルが破損パケットをドロップして再送を促すため転送が成功するようになり、問題は一時的に棚上げされた。
転機は2026年。NixOSへの移行作業中、Fastly CDNからの128MiBファイルがHTTP/2では失敗しHTTP/1.1では成功することを発見。wget経由のNixOS ISOダウンロードも「decryption failed or bad record mac」というTLSエラーで2.7GB地点で中断された。
デバイスのファームウェアは出荷時の「1.0.0 Build 20230605 Rel.71641」のまま更新ゼロ。2025年にサポートへ問い合わせたところ、「EAP770 v1はEOL製品でファームウェア更新は提供しない」との回答が返ってきた。Wi-Fi 7標準自体が2024年9月に正式確定したため、同製品はWi-Fi Allianceの認証も取得していない。
dfb氏はBPFプローブでラップトップのWi-Fiドライバを調査し、アクセスポイント側でapstatsをroot権限で実行。根本原因はsysfsの特定パラメータに「00」を書き込めば修正できることを突き止めたが、TP-Linkのシェルはそのパスへの書き込みを制限していた。そこで氏はQualcomm IPQ9574上で動くLinux 5.4.164に対するカーネルexploitをゼロから書き、制限を迂回してパラメータを書き込むことで自力修正を完了させた。なお、毎日11時に起きるWi-Fi切断は別バグと判明し、ラップトップ側のQualcomm Wi-Fiカードのクローズドソースファームウェアに起因することが後に判明した。