When Wi-Fi Corruption Leads to a Kernel Exploit

An ISO image—a bootable disk image—is supposed to be boring. Start wget, wait, verify the hash, and move on. On one TP-Link EAP770 v1 access point, though, large downloads over Wi-Fi arrived with a 64-byte region replaced by stale data. Transmission Control Protocol (TCP) reported a valid checksum, while Transport Layer Security (TLS) and Secure Shell (SSH) rejected the damaged content. The eventual workaround was two zeros in Linux's sysfs, a live interface for changing kernel settings. Reaching those two files required a local kernel exploit. (blog.dfb.sh)

The first clue was a checksum that lied

Why would a Wi-Fi access point corrupt a download while TCP insists the packet is valid? That question became the turning point.

A TCP segment is one chunk of a TCP connection, complete with headers and a payload. Its checksum is a small transport-level integrity check designed to catch accidental damage. It is not the same as the end-to-end protection used by TLS or SSH. Those protocols also calculate message authentication codes, usually called MACs, over the protected data. When the bytes changed, TLS reported bad record mac and SSH reported a corrupted MAC, even though TCP had accepted the segment.

The investigation moved away from application software and toward the network path. A raw TCP test sent known bytes between a wired machine and a Wi-Fi laptop. The corruption appeared only with several streams running at once, only from the local network toward Wi-Fi, and in three 64-byte blocks across 8192 MiB of data. Wired clients stayed clean, and the wireless link's own integrity tag was intact. That ruled out the download server, the Ethernet cable, and ordinary radio interference.

The hidden path was the access point

An access point is more than a radio. It also bridges traffic between Ethernet and Wi-Fi, often using hardware acceleration so packets do not have to travel through every ordinary CPU networking layer. Qualcomm calls parts of this fast path the Shortcut Forwarding Engine, or SFE, and the Packet Processing Engine, or PPE.

The 64-byte size was a particularly sharp clue. On the Qualcomm IPQ9574 hardware in this access point, it matches a CPU cache line—the smallest block of cached memory normally moved between the processor and memory. That suggested a cache or direct memory access problem rather than random bit flips. Direct memory access, or DMA, lets network hardware read and write memory without asking the CPU to copy every byte.

The relevant fast-path controls were exposed as two kernel attributes:

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

These are not ordinary configuration files. sysfs presents kernel objects and their attributes as files, allowing user space to inspect or change selected runtime behavior. Writable attributes are normally restricted to privileged users because a careless write can alter hardware or kernel behavior. (docs.kernel.org)

The fix was small, but root was not available

The device's restricted SSH shell ran with user ID 1 and no useful Linux capabilities. In other words, it could run a limited collection of commands but could not write the SFE settings. There was no supported firmware image for the affected hardware revision, no graphical switch for disabling the offload, and flashing the storage chip directly risked turning a networking problem into a dead access point.

That left an awkward gap between ownership and control. The needed repair was known, the device was physically in the owner's home, and yet the software boundary prevented the owner from applying it.

Why a kernel exploit entered the story

The route around that boundary used CVE-2022-0185, a Linux kernel vulnerability in legacy filesystem-parameter handling. A Common Vulnerabilities and Exposures, or CVE, entry gives a flaw a standard identifier so vendors and researchers can discuss it consistently.

The bug involved an integer underflow: a length calculation could wrap around when a buffer became nearly full. The kernel then believed there was far more room than actually existed and wrote beyond a 4 KiB slab object. A slab is a kernel memory allocator area used for objects of similar sizes.

The vulnerable path could be reached from an unprivileged user namespace. A user namespace gives a process its own isolated view of user and group identities, and Linux can grant that process capabilities inside the namespace even though it remains unprivileged outside it. The kernel documentation describes this feature as useful for isolation, but also recognizes that namespace-reachable bugs can become security boundaries. (access.redhat.com)

The exploit chain then used Linux pipe buffers. A pipe buffer is kernel metadata describing a memory page and the portion of that page associated with a pipe. By corrupting carefully arranged metadata, the overflow could be turned into a controlled write to kernel memory. The details are highly dependent on the exact kernel build, allocator layout, and enabled protections, which is why the exploit was first developed in a QEMU test harness with a matching configuration before being adapted to the access point. Linux's pipe implementation exposes the relevant page and operation structures that make this class of manipulation possible. (kernel.org)

This was not a remote attack against an unsuspecting router. It was a local privilege escalation used to modify a device already under its owner's control. The exploit also had to leave the access point running, because the two settings reverted after a reboot and the damaged slab state made a second attempt unsafe.

The suspected root cause was cache coherency

The working diagnosis was a DMA cache-coherency bug in Qualcomm's packet-buffer recycling path. Think of the CPU cache as a fast, private copy of recently used memory. The network processor writes a fresh packet into main memory, but the CPU may still hold an older version of part of that buffer. Cache coherency is the machinery that keeps those copies consistent.

The driver reused packet buffers after fast transmission. In the receive path, a flag could tell the driver that a buffer had already been invalidated, so it skipped invalidating the receive region again. If dirty cache lines remained from the previous use, the CPU could later write those old 64-byte blocks back to memory after the network hardware had placed a new packet there. The result was a packet with a small, repeatable patch of stale data.

The fast path then made the symptom harder to interpret. A checksum calculated before the overwrite would no longer describe the final bytes, while a later checksum calculation could produce a perfectly valid checksum for already-corrupted data. TLS and SSH still caught the mistake because their integrity checks covered the original end-to-end content. The public driver code shows the fast-recycle flag being set on transmit and used to skip receive-buffer invalidation. (blog.dfb.sh)

Correctness cost about eight percent

Disabling the offload fixed the corruption but reduced throughput. With acceleration enabled, an 8192 MiB test reached 103.4 MiB/s and produced three bad blocks. With it disabled, an overnight run produced no bad blocks at roughly 95.4 MiB/s—about an 8 percent performance cost. That is a painful trade, but a slower download that arrives intact is more useful than a fast one that fails near the end.

A VPN had previously appeared to solve the problem. WireGuard authenticated its outer packets and discarded damaged ones, so the TCP connection inside the tunnel saw packet loss and retransmitted. The tunnel did not repair the access point; it moved detection earlier in the stack.

The lasting lesson is broader than one abandoned access point. Checksums at one layer do not guarantee correctness at every layer. Hardware offload paths deserve their own stress tests, especially on systems where CPU caches and DMA are not transparently coherent. And when a vendor leaves a device on old firmware, a two-line runtime workaround can become a security research project. The ISO download finally succeeded, but only after a failure in networking, memory management, and product support all met in the same small box.