Wanted to download an ISO, ended up writing a kernel exploit

> The connection was a bit janky, a video would occasionally start buffering, but it didn't bother me much.

This is truly bonkers! Please, if you buy hardware that does not work correctly from day 1, return it. If you do not vote with your wallet these companies will never learn and will never adjust their practices. Rewarding TP-Link by keeping their terrible hardware does nothing.

> I contacted support in June because the website only had firmware for v2. They couldn't find v1 in their database and asked for photos of the device and box

!!

The Q1000K ONT(which also has an optional router feature) used by a major US ISP[0] has some rather crazy driver bugs I used AI to root cause and even live patch[1] as a proof of concept to fix(I found some 6RD protocol corruption bugs as well). Getting root access was also trivial by simply feeding it a copy of the firmware binary. In this case the bug originated from the SoC vendor[2] which I reported to them and they seemed to confirm it(with hopefully fixes making it into new firmware updates). It's pretty crazy how good AI is at reverse engineering and root causing bugs in embedded systems these days. Even stuff like BROM dumps(which are usually heavily stripped) are easily analyzed and even live patched[3] by AI.

[0] https://www.quantumfiber.com/

[1] https://github.com/jameshilliard/q1000k-hsgmii-pad

[2] https://www.airoha.com/

[3] https://github.com/linux-sunxi/sunxi-tools/pull/234

Really happy with my Flint 3. I like that I can SSH to root and do whatever I want.

But what really shocked me is how amazing GL.Inet support is. I think they're probably the best support people I've come across, helping me track down an issue I've had for months with an Aqara doorbell that intermittently goes offline, suggesting configuration changes, even logging into my router (with my permission) to diagnose things. Don't have to register an account in any support system or forum either, can do everything over email. Complete opposite to pretty much every networking vendor I've encountered both low end and enterprise.

Great write-up!

Not surprised by the driver software quality issues. When I was still working in consumer electronics / embedded, I saw many examples of the internals of those devices. The software was often a hodgepodge of scripts and drivers, whatever seemed to work, from companies without a great software and details culture.

We would usually rewrite the drivers entirely from the datasheets or from reversing the vendor ones!

> I have the Cyber Verification Program enabled on my account, which hasn't helped.

This is funny to read. Either you can be more "verified" than the other guy, or it's badly implemented.

I worked on a very similar bug in the past, just with another ipq and another pcie card.

IMO, The issue is that cache coherency is not very well specified, and usually defined at the SoC/platform level.

Meaning, you could have the same arm core on 2 different SoCs, running the same driver with the same PCIe card and you will get corrupted data on the one where the PCIe controller‘s requests do not snoop the cpu cache.

Also, note that for both rx/tx to work, you need to invalidate on both sides: rx need to access the dram and not cache. tx need to verify that all was written to the dram before giving it to the hw.

I hope things are better now, but there used to be 1.5 poor choices:

1) use uncached DMA buffers 2) manage cache host CPU coherency by hand. 3) hope you only ran on hardware cache coherent architectures

And the kernel didn't give you everything you needed to do #2.

Just reading a USB2 480p webcam on a raspberry pi burned half the CPU kernel memcpying pixels from uncached DMA rx buffer to cacheable buffer. At least the camera is a linear copy, but the USB packets are relatively small.

Shopping for new router/AP should start with looking at OpenWRT, it's just a lottery relying on vendor hardware.

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.

Small world - I saw your "rant" thread on /r/TPLink_Omada before I rolled the dice on EAP770 a few weeks ago

It won't be much consolation, but I received a v2 and applied several firmware updates after unboxing it

Seems solid, although I noticed 'exit' doesn't work in ssh (?) - need to type ~. instead

Wait TP-link EOL their fancy Wifi-7 router. Jezz how long do they support their product, 1 month ?

To raise awareness, the author also asks Hacker News for Security reporting help, in the post description above:

> Author here. Does anyone know what to do with the rest of the drivers? I found at least 13 in-tree drivers with the same bug class. The nasty part is they work fine on x86 and silently corrupt data on arm and other non-coherent archs, and I don't have the hardware to test them.

.. who can help them?

I’m surprised you didn’t use your shiny exploit to get enough access to write a startup script or give yourself root. Or patch the driver :)

(I’ve had Astra suggest binary patches things when I don’t even ask it to.)

re: the DMA API, it’s been a while since I’ve poked at it (and I’ve only really poked seriously on x86 Xen PV), but I think there are explicit APIs for cache maintenance, and you drivers may also be able to ask for more coherent mappings depending on hardware. You’re certainly not expected to stick arch-specific flush operations in.

> Wanted to download an ISO, ended up writing a kernel exploit.

..from the diary of an AI agent.

Does TP-Link just make buggy stuff, or are we just unlucky? I used to have a TP-Link WiFi 6E router, that I used as an access point and a switch (the "routing" was disabled since I use another router).

For whatever reason, that device would drop packets if they were VLAN-tagged. Other packets were fine, but anything to do with VLAN just didn't work. Took me a while to figure out that was the issue and it wasn't with the machine I was trying to configure.

I sold that thing on eBay and replaced it with a "real" access point (and a PoE switch).

For some reason I read a long time ago that offloading is unreliable and I turn it off everywhere. I’m glad that the author also had to turn it off to fix Qualcomm’s bugs. But in general, is this still good advice in 2026?

upd: reported the bug to qualcomm and tp-link. will update the post if either of them gets back to me

This is why I use openwrt where supported.

It’s cool but couldn’t you return the broken hardware to the store?

I have done some similar work.

First, when Claude refuses I sometimes continue with Kimi or DeepSeek. They are less squeamish. Alas, the combination of C + kernel reliably makes Claude freak out: because of all the UB any tiny error becomes a security hole. (I have the cybersecurity verification stuff from OpenAI and Anthropic but they are still fairly strict.)

Second, contributing directly to the Linux kernel has never been easier. Claude knows all about how to interact with the archaic kernel mailing lists. The main rule I suggest: put in real effort, don't dump AI slop.

However I mostly worked in fixing filesystem bugs so far. I don't know whether the networking and DMA folks are as nice. But probably yes.

(Coincidence: the isofs filesystem code in the kernel is full of tiny holes as far as I can tell. I've patched some of them, but better don't try to mount a malicious CD image.)

So what is a good router nowadays? I'm about to buy one and I'm not looking towards this particular rabbit hole.

Ugh, TP-Link, I hate those, they are pure garbage

> TLS, which rejected the record with bad record mac.

Does TLS (transport layer) not have any retry logic? Could someone explain please?

you mean chatgpt wrote the kernel exploit

[flagged]

[flagged]

[flagged]

[flagged]

I guess you meant chatgpt wrote the kernel exploit.