Developer writes kernel exploit for his own TP-Link EAP770 after vendor EOL'd buggy firmware

An access point that corrupted its own downloads

According to a detailed write-up on the developer's blog at dfb.sh, which reached the front page of Hacker News, the story began in August 2023 with the purchase of a TP-Link EAP770 v1, a Wi-Fi 7 access point built on a Qualcomm IPQ9574 SoC running Linux 5.4.164. Wi-Fi transfers to a laptop started failing on files larger than a few GiB, with SSH reporting MAC errors. Because Wireshark showed zero bad checksums and zero retransmissions, and a single UDP stream of random bytes came through clean, the developer initially blamed rsync and SSH, wrote a retry wrapper, and moved on.

An accidental workaround appeared later: once Tailscale carried traffic inside the home network, the failures effectively vanished. WireGuard drops any packet whose authentication fails, so the TCP connection inside the tunnel simply retransmitted the damaged data — masking the bug rather than fixing it.

Notably, the Wi-Fi 7 standard was only finalized in September 2024, the device carries no Wi-Fi Alliance certification, and the AP never received a firmware update beyond the build it shipped with.

End-of-life before it was even unboxed

In June 2025, after noticing that everything else in the house was getting updates while the AP stayed on its original firmware, the developer contacted TP-Link. The vendor's website only offered firmware for the v2 hardware, support initially could not find the v1 in its database and asked for photos of the device and box, and then confirmed that the EAP770 Version 1 is an end-of-life product no longer supported with firmware updates. The v2 firmware targets different hardware, the sibling EAP773's image was rejected by the device, and newer v2 releases are encrypted — leaving no legitimate path to a patched unit.

64 bad bytes with a valid checksum

Renewed debugging in 2026, aided by an LLM and BPF probes, produced the smoking gun: a tcpdump capture of a failing HTTPS download showed a 1440-byte TCP segment containing 64 consecutive wrong bytes — with a valid TCP checksum. TcpInCsumErrors stayed at zero, meaning something on the path had corrupted the payload and then recalculated the checksum.

Raw TCP tests between a wired machine and the Wi-Fi laptop showed the corruption only with several concurrent TCP streams, only in the LAN-to-Wi-Fi direction, and produced three bad 64-byte blocks across 8192 MiB, each starting with zeros. Sixty-four bytes is a cache line on the IPQ9574's cores, pointing at a cache or DMA bug rather than a flipped bit. Swapping the laptop's Wi-Fi card did not help, wired clients were clean, and the CCMP MIC on the bad frames was intact. That left the bridge inside the AP, and the only component there that both accelerates bridged traffic and rewrites checksums: Qualcomm's SFE/PPE offload. The daily drops around 11:00 turned out to be a separate bug in the laptop's Wi-Fi card firmware.

Two zeros that need root

Reading the driver source suggested a fix: writing 0 to /sys/sfe/l2_feature and /sys/sfe/ppe_rfs_feature to disable the offload. But those sysfs files are root-only, TP-Link's SSH shell runs as uid 1 with no capabilities, and there is no GUI setting. With no patchable firmware image and no appetite for hunting down a flash clip and risking a brick, the developer concluded the only way in was the kernel.

TP-Link's userland turned out to be genuinely hardened — whitelists everywhere, minimal modules, no vectors in the vendor's own binaries. So the developer assembled a chain from CVE-2022-0185, an integer underflow in the kernel's legacy_parse_param() reachable from an unprivileged user namespace that yields a heap overflow, combined with pipe-buffer manipulation to turn it into an arbitrary write, building on existing public write-ups. The exploit had to leave the AP running, since the broken offload returns after a reboot, and the overflow leaves the kernel in a state where a second attempt panics: one shot per boot.

Development happened in a QEMU harness built from the EAP783's published GPL sources, whose kernel config differs from the AP's by three cosmetic lines. The AP's kernel has no KASLR but zeroed kallsyms, and its physical load address and section offsets differ from the QEMU build, forcing address recovery at runtime.

Why it matters

This is a rare, fully documented case of a customer having to exploit his own hardware to work around a defect the vendor declined to fix. It illustrates several uncomfortable realities: pre-standard devices can be abandoned the moment a successor ships; hardware offload engines can silently corrupt data in ways that defeat TCP's integrity checks, leaving TLS as the last line of defense; and sysfs knobs exist for exactly this kind of mitigation but are unreachable when vendors ship locked-down shells on EOL products. It also shows how much of this labor — from tracing corruption to stabilizing an exploit chain — is now tractable with an LLM as a debugging partner.