--- title: Wanted to download an ISO, ended up writing a kernel exploit description: A TP-Link EAP770 v1 Wi-Fi 7 access point was silently corrupting large downloads over Wi-Fi, traced through months of debugging with tcpdump, raw TCP tests,... canonical: https://daily.dev/posts/wanted-to-download-an-iso-ended-up-writing-a-kernel-exploit-lqzsyrsxr twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Wanted to download an ISO, ended up writing a kernel exploit | daily.dev og:description: A TP-Link EAP770 v1 Wi-Fi 7 access point was silently corrupting large downloads over Wi-Fi, traced through months of debugging with tcpdump, raw TCP tests,... og:url: https://daily.dev/posts/wanted-to-download-an-iso-ended-up-writing-a-kernel-exploit-lqzsyrsxr og:image: https://api.daily.dev/og/posts/lQzSyrsXR.png og:image:alt: Wanted to download an ISO, ended up writing a kernel exploit og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Wanted to download an ISO, ended up writing a kernel exploit **[Hacker News](https://daily.dev/sources/hn)** · 16 min read · 0 upvotes · 0 comments ## Summary A TP-Link EAP770 v1 Wi-Fi 7 access point was silently corrupting large downloads over Wi-Fi, traced through months of debugging with tcpdump, raw TCP tests, and BPF probes to a DMA cache coherency bug in Qualcomm's out-of-tree qca-nss-dp SFE/PPE offload driver: a recycled receive buffer skips cache invalidation after a fast-transmit path, letting stale dirty cache lines overwrite freshly received packet data, after which the offload recalculates a valid TCP checksum over the corrupted payload so only end-to-end MACs (TLS, SSH) catch it. The fix is writing two zeros to sysfs files to disable the offload, but TP-Link's locked-down shell runs as a non-root user with no capability to do so, and the device was declared end-of-life before being unboxed. With AI assistance (Opus 4.8), the author built a kernel exploit chaining CVE-2022-0185 with pipe-buffer manipulation to gain root, disable the offload, and persist the fix with a watcher script that re-runs the exploit after every reboot. A separate section covers tracking down unrelated Wi-Fi transmission stalls traced to the laptop's closed-source ath12k/WCN785x firmware. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What causes TCP downloads over Wi-Fi to get corrupted with valid checksums but fail TLS or SSH MAC verification? A DMA cache coherency bug in Qualcomm's qca-nss-dp driver used in SFE/PPE hardware offload is the cause on affected APs. When a transmitted buffer is recycled for receive, the driver skips cache invalidation because it assumes the buffer was already clean, so a leftover dirty cache line gets written back over part of the newly received packet. The offload then recalculates a fresh, valid TCP checksum over the corrupted payload, so only end-to-end integrity checks like TLS or SSH MACs detect the damage. _Anyone debugging mysterious Wi-Fi data corruption can follow root-cause writeups like this one on daily.dev._ ### How does CVE-2022-0185 get escalated into an arbitrary kernel write using pipe buffers? CVE-2022-0185 is an integer underflow in legacy_parse_param(), reachable from an unprivileged user namespace, that overflows a 4 KiB slab object. Combined with pipe-buffer manipulation, the overflow enlarges a victim key's metadata to leak a pipe's buf[0].ops pointer (anon_pipe_buf_ops), which is then used to forge a ring entry so pipe_buf_can_merge() accepts writes to an arbitrary physical page, including kernel image pages. _Developers studying real-world kernel privilege escalation chains can track exploit writeups like this on daily.dev._ ### Why does disabling SFE/PPE hardware offload fix Wi-Fi download corruption on Qualcomm IPQ9574 access points? Disabling the offload via sysfs writes of 0 to /sys/sfe/l2_feature and /sys/sfe/ppe_rfs_feature stops buffers from taking the fast transmit path that sets the fast_recycled flag, so the receive path performs full cache invalidation again before handing buffers to the NIC. In testing, this eliminated all corrupted 64-byte blocks in an overnight transfer, at a cost of about 8% download throughput (103.4 MiB/s to 95.4 MiB/s). _Engineers weighing throughput against data integrity on offload-heavy routers can find deep dives like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 3 discussions and 104 comments across hackernews (as of 2026-10-15). **TL;DR:** Most of the technical praise goes to the debugging write-up itself, while a large side-thread pivots into complaints about AI coding assistants refusing security-related tasks, and many commenters use the story as another reason to distrust TP-Link and hardware offload in general. **Sentiment:** 20% positive · 35% mixed · 45% skeptical **The case for** - The debugging methodology (tcpdump, raw TCP tests, BPF probes) was widely admired as an impressive and well-documented piece of detective work. - Several people pointed out that checksum-offload-after-corruption bugs are an important, under-appreciated lesson about not blindly trusting TCP checksums. - Some praised using AI assistance for real kernel/security work as a legitimate, productive use case when it isn't blocked by refusals. **The pushback** - Many commenters are frustrated that AI models (especially Claude/Anthropic) refuse or hamper legitimate security and kernel-level debugging tasks, forcing people to switch to other models. - TP-Link is repeatedly criticized for poor support, shipping unsupported/EOL hardware, inconsistent firmware availability, and generally buggy devices across multiple product lines. - Commenters note hardware offload bugs are common industry-wide (not unique to TP-Link) and that closed-source blobs in WiFi drivers make this kind of silent corruption hard to catch. - Some argue OpenWrt/alternative router vendors (Ubiquiti, Mikrotik, FritzBox, GL.iNet) should be the default choice specifically because of this class of problem. **By community** - hackernews (mixed): Discussion splits between genuine appreciation for the technical write-up and a long tangent criticizing AI assistant refusals plus general distrust of TP-Link hardware. **Hottest debate:** Whether AI coding assistants' safety refusals on security/kernel topics are a reasonable precaution or just unhelpful, inconsistent 'morality theater' that pushes people to less-restricted models. **Open questions** - Is the underlying DMA cache-coherency bug still present in other devices using the same Qualcomm qca-nss-dp driver tree? - Would mandatory multi-year firmware update requirements (e.g., EU Cyber Resilience Act) actually have prevented this kind of unsupported hardware situation? **Highlights** > Checksum offload, recalculating a bad checksum after corrupting the data, is really insidious. Shows that trust in TCP can be badly misplaced -- in this case the trouble was cache coherency, but lack of ECC RAM or other electrical gremlins could easily corrupt packets too (and NIC buffer RAM is never ECC afaik), and blindly trusting TCP checksums would eat your data every time. (Side note, doesn't 'zfs send' blindly trust TCP checksums?) Props to Rsync and SSH and Wireguard and everything else that went beyond the call of duty to keep your data safe, with varying levels of alertness. > — [myself248 on hackernews · 4 comments](https://news.ycombinator.com/item?id=50102256) > TLS uses TCP, and TCP has checksums and retry logic. It therefore assumes any data corruption that made it all the way to the TLS layer is an unrecoverable scenario, probably indicative of an attack. The problem here is that the thing computing the TCP checksum on the outgoing frame was the WLAN firmware running on the WLAN NIC itself; this is known as checksum offloading. It saves CPU time if the CPU can just hand off a TCP segment to the NIC and let the NIC checksum it before it sends it out. This only works properly if the data given to the NIC doesn't get corrupted in the meantime. > — [aaronmdjones on hackernews](https://news.ycombinator.com/item?id=50101120) > Step one is not to buy TP-Link routers. I know people have limited budgets, but having seen the code that sits on these devices and how poor quality and easily exploited it is, time and time again, I'll never buy TP-Link (amongst others) again. For a while I collected a graveyard of routers that had been abandoned by the manufacturers (and contained serious vulnerabilities), with the intention of writing them all up one day; next thing you know I have two children rapidly reaching double-digit ages, and much better things to do with my life than write about how shitty the code is on actual products we buy every day. I switched, about 7-8 years ago to a Protectli box running Coreboot and OPNSense and haven't looked back; I use Ubiquiti APs and switches. I'm not saying they're the best, but anything used in corporate/enterprise is going to have better support (if not better code quality). The great thing about Ubiquiti APs for me is that each new WiFi generation (or two) I can just buy a few more, snap the existing APs off of the various ceilings they're attached to, snap on the new ones, adopt them, and away we go. > — [alias\_neo on hackernews · 7 comments](https://news.ycombinator.com/item?id=50101726) > Claude's 'nanny knows best' recalcitrance towards any sort of defensive security task is driving me away from Anthropic as a customer. GLM doesn't give me this nonsense, DeepSeek doesn't give me this nonsense; as you say Anthropic's silly paternalism around security prevents nothing in practice, it's just a burdensome morality-laundering tax on everyone's time and lifeblood. Also imagine having the gall to push a class of technology on the world that dramatically drives up the number of attacks, then refusing to allow said products to be used defensively to avoid the consequences. Who do these people actually think they're kidding? > — [BoxOfRain on hackernews · 1 comments](https://news.ycombinator.com/item?id=50101487) > Wait TP-link EOL their fancy Wifi-7 router. Jezz how long do they support their product, 1 month ? > — [mrheosuper on hackernews · 3 comments](https://news.ycombinator.com/item?id=50101439) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50070625) · 204 points · 102 comments - [hackernews](https://news.ycombinator.com/item?id=50090900) · 4 points · 2 comments - [hackernews](https://news.ycombinator.com/item?id=50100704) · 2 points · 0 comments ## Similar posts on daily.dev - [A Deep Dive Into Attempted Exploitation of CVE-2023-33538](https://daily.dev/posts/a-deep-dive-into-attempted-exploitation-of-cve-2023-33538-prhsvxjqs) · Unit 42 · 0 upvotes · 0 comments - [Hacking A Tenda AC1200 Wi-Fi Router With A CVE Combo](https://daily.dev/posts/hacking-a-tenda-ac1200-wi-fi-router-with-a-cve-combo-psnxwd458) · Hackaday · 2 upvotes · 0 comments - [Linux Fixes Performance Bug Affecting Qualcomm Ath11k & Ath12k WiFi Drivers](https://daily.dev/posts/linux-fixes-performance-bug-affecting-qualcomm-ath11k-ath12k-wifi-drivers-ierbuumdb) · Phoronix · 0 upvotes · 0 comments - [D-Link warns of max severity zero-day bug in DIR-822A routers](https://daily.dev/posts/d-link-warns-of-max-severity-zero-day-bug-in-dir-822a-routers-qt5pbasg1) · BleepingComputer · 0 upvotes · 0 comments --- Tags: [#networking](https://daily.dev/tags/networking), [#reverse-engineering](https://daily.dev/tags/reverse-engineering), [#dma](https://daily.dev/tags/dma) [View this post on daily.dev](https://daily.dev/posts/wanted-to-download-an-iso-ended-up-writing-a-kernel-exploit-lqzsyrsxr) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Wanted to download an ISO, ended up writing a kernel exploit","url":"https://daily.dev/posts/wanted-to-download-an-iso-ended-up-writing-a-kernel-exploit-lqzsyrsxr","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/wanted-to-download-an-iso-ended-up-writing-a-kernel-exploit-lqzsyrsxr"},"datePublished":"2026-10-15T08:57:43.248Z","dateModified":"2026-10-15T13:44:00.724Z","description":"A TP-Link EAP770 v1 Wi-Fi 7 access point was silently corrupting large downloads over Wi-Fi, traced through months of debugging with tcpdump, raw TCP tests,...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/5fccf606090e43b7cc94d0ff61916a31?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/5fccf606090e43b7cc94d0ff61916a31?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/wanted-to-download-an-iso-ended-up-writing-a-kernel-exploit-lqzsyrsxr","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"networking,reverse-engineering,dma","timeRequired":"PT16M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Wanted to download an ISO, ended up writing a kernel exploit"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/wanted-to-download-an-iso-ended-up-writing-a-kernel-exploit-lqzsyrsxr#faq","mainEntity":[{"@type":"Question","name":"What causes TCP downloads over Wi-Fi to get corrupted with valid checksums but fail TLS or SSH MAC verification?","acceptedAnswer":{"@type":"Answer","text":"A DMA cache coherency bug in Qualcomm's qca-nss-dp driver used in SFE/PPE hardware offload is the cause on affected APs. When a transmitted buffer is recycled for receive, the driver skips cache invalidation because it assumes the buffer was already clean, so a leftover dirty cache line gets written back over part of the newly received packet. The offload then recalculates a fresh, valid TCP checksum over the corrupted payload, so only end-to-end integrity checks like TLS or SSH MACs detect the damage. Anyone debugging mysterious Wi-Fi data corruption can follow root-cause writeups like this one on daily.dev."}},{"@type":"Question","name":"How does CVE-2022-0185 get escalated into an arbitrary kernel write using pipe buffers?","acceptedAnswer":{"@type":"Answer","text":"CVE-2022-0185 is an integer underflow in legacy_parse_param(), reachable from an unprivileged user namespace, that overflows a 4 KiB slab object. Combined with pipe-buffer manipulation, the overflow enlarges a victim key's metadata to leak a pipe's buf[0].ops pointer (anon_pipe_buf_ops), which is then used to forge a ring entry so pipe_buf_can_merge() accepts writes to an arbitrary physical page, including kernel image pages. Developers studying real-world kernel privilege escalation chains can track exploit writeups like this on daily.dev."}},{"@type":"Question","name":"Why does disabling SFE/PPE hardware offload fix Wi-Fi download corruption on Qualcomm IPQ9574 access points?","acceptedAnswer":{"@type":"Answer","text":"Disabling the offload via sysfs writes of 0 to /sys/sfe/l2_feature and /sys/sfe/ppe_rfs_feature stops buffers from taking the fast transmit path that sets the fast_recycled flag, so the receive path performs full cache invalidation again before handing buffers to the NIC. In testing, this eliminated all corrupted 64-byte blocks in an overnight transfer, at a cost of about 8% download throughput (103.4 MiB/s to 95.4 MiB/s). Engineers weighing throughput against data integrity on offload-heavy routers can find deep dives like this on daily.dev."}}]} ```