From ISO Download to Kernel Exploit

TL;DR: My TP-Link EAP770 v1 was corrupting Wi-Fi downloads, and TP-Link declared it End-of-Life (EOL) before I even took it out of the box. Since their restricted shell blocked the necessary fixes, I wrote a kernel exploit to seize control of my own hardware.

---

📉 The Mystery of the Breaking Downloads

Back in August 2023, I picked up a TP-Link EAP770, a high-end Wi-Fi 7 access point. Initially, things seemed fine—just some minor buffering here and there. However, a pattern emerged when I tried to rsync my home directory to my laptop: transfers larger than a few GiB consistently failed.

I spent significant time troubleshooting:

• SSH reported MAC errors.
• Wireshark showed no retransmissions and perfect checksums.
• UDP streams of random data arrived without a single error.

Because I trusted TCP to do its job (which is literally its only job), I assumed the fault lay with rsync or SSH. Curiously, when I started routing internal traffic through Tailscale, the problem vanished. Because WireGuard discards packets that fail authentication, the inner TCP connection simply saw a lost packet and retransmitted it, masking the underlying corruption.

🚫 The "Support" Experience

My hardware specs were as follows:

I realized the device hadn't received a single update since launch. Considering the Wi-Fi 7 standard wasn't even finalized until September 2024, buying this early was a great idea it was a mistake to buy uncertified gear.

When I contacted support in June 2025 to ask why only v2 firmware was available, they told me they couldn't even find v1 in their database. After I sent photos of the box, they responded:

"The EAP770 Version 1 is an End-of-Life product. While it may still be available through some retailers, it is no longer supported with firmware updates."

🔍 Hunting the Corruption

By 2026, the issues became impossible to ignore. While switching to NixOS, I noticed a strange discrepancy: a 128 MiB file from the Nix binary cache failed over HTTP/2 but worked over HTTP/1.1. I suspect HTTP/2's increased speed simply triggered the bug more frequently.

The failures were widespread:

• git clone failures
• HTTPS "bad record mac" errors
• wget TLS crashes

One specific error stood out:

2026-03-05 12:37:18 (31.6 MB/s) - Read error at byte 2722477636/3683778560 (error:0A000119:SSL routines::decryption failed or bad record mac; error:0A000139:SSL routines::record layer failure).

I decided to investigate using Opus 5.5, applying BPF probes to the laptop's Qualcomm driver and running apstats on the AP. After replacing my MediaTek adapter with a Qualcomm one and disabling GRO (Generic Receive Offload), the corruption persisted.

The Smoking Gun

Using tcpdump, I found a 1440-byte TCP segment containing 64 consecutive corrupted bytes—yet the TCP checksum was valid. This meant something after the corruption had recalculated the checksum.

I tested raw TCP streams between a wired machine and the laptop. The corruption only occurred during simultaneous TCP streams moving from LAN to Wi-Fi. I found three corrupted blocks of 64 bytes in 8 GiB of data.

The math points to a hardware issue: $\text{Corruption Block Size} = 64 \text{ bytes} = \text{Cache Line of IPQ9574}$

This suggested a DMA or cache bug in the Qualcomm SFE/PPE offload (the system that accelerates bridged traffic and handles checksums).

🔓 The Wall and the Breach

To stop the corruption, I needed to disable the SFE/PPE features. The driver source indicated I needed to run:

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

The Problem: These files require root privileges. TP-Link's SSH shell provides a user with uid 1 and zero capabilities. I couldn't flash v2 firmware (wrong hardware) or use the EAP773 firmware (rejected).

I refused to spend another $200 because of a manufacturer's refusal to provide basic updates. Since the binaries were heavily whitelisted and secure, I turned to Opus 4.8 to build a custom exploit chain.

By leveraging CVE-2022-0185 combined with pipe-buffer manipulation, I successfully bypassed the restrictions and gained the root access necessary to fix my own device.