0xdeafbeef

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

Too many exploits is not a that big problem. Non of new fancy exploits with cvss 10.0 from 2026 have worked for this ap. If you don't use all the drivers you have small attack surface. I'd say that it's a surviviourship bias. Bsd has less traction => less bugs found

It's not a router, it's an AP, so in my mind it's just a LAN to wifi bridge, a wrapper around the chip :) People were recommending them, it has PoE, roaming works etc. I thought I could buy a consumer product and stop tinkering lol. I'll check Ubiquiti, but I somehow thought that they are overpriced af and never looked into them

Nah bug is still in the qcom tree. I've not checked how many devices use it though

It was EOL from the factory. 0 updates. But other routers I "own" receive updates regularly so I guess I won some lottery.

They often have logic in blobs and run a separate OS inside. See all wifi 7 drivers, all come with blobs and OSS driver simply is a bridge

Nope. It was bought in the other country, tplink said to return it where it was bought. I don't even remeber where it was :)

They have 3 tiers, individuals can have only blue teaming. But it's to restricted. For me it refused to fix a bash parser cause word ssh was in test cases.

Or fix an sql injection

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.

I'd guess that's what the DMA API is for and drivers shouldn't be doing cache maintenance by hand, but I'm not a kernel dev, so maybe I'm missing something.

Better to have golden tests. Even switch from cpu to gpu can give you different tokens

uintptr_t x = opaque((uintptr_t)p); free((void *)x); free(p);

How will you find such violations if opaque comes from so or some ffi, so compiler can't see through? you can't. It's heuristics. Sound type system is much stronger

https://likec4.dev/ It's a bit different usecase, but llms are proficient with it

Sounds similar to https://mlir.llvm.org/

Todo type in rust will be a never type. Eg thing which exit or panic returns

Location: Belgrade, Serbia Remote: Yes Willing to relocate: Yes, preferably EU/UK Technologies: Rust, Python, C, RocksDB, PostgreSQL, Kafka, ClickHouse, TiDB, Vector, Linux hacking, eBPF, Docker, Kubernetes, Ansible, Terraform, GCP, GitLab CI, GitHub Actions Résumé/CV: Available on request. GitHub: github.com/0xdeafbeef, LinkedIn: linkedin.com/in/petrzhikovskii Email: [email protected]

I was thinking about transaction processing, eg visa/blockchain. And here storing and sending almost full packet for signature instead of 32 bytes matters. For sessions this shouldn't matter

Cost is 100+ times bigger signature size and more cpu usage. If you process several k per second it matters

Try g.ai. It's stupid fast and uses google indexes. Kagi? sometimes doesn't correctly parse intent, in Google thing you can just ask function doing this and gives you it, with examples, grounding and extremely fast. I'm paying for kagi since the begging and I guess id cancel it because it gives not so much added value

Care to opensource? I'd like to use it in firefox, will send a pr

Filed an issue for codex

https://github.com/openai/codex/issues/11601

Bftree solves one non-obvious pain point - caching when your data set is random (the key is a hash) and the data is smaller than the page size. LSM reads are based on block size; same with caching. So if your record is 8 bytes, you end up caching the remaining ~4 KB, and the hit rate will be pretty low.

I've tested with wal enabled, got deadlock several times, so looks raw for now

It was 1 year ago. Around 15 tikv serves, 32 cpu, 128 ram each, 4 tb nvme. In this case latency matters a lot. When i had load server in different region with ping of 3ms I got 70k inserts, when moved to the same region with sub ms ping it went to thousands

Tidb should handle it nice. I've wrote 200к inserts / sec for hour in peak. Underlying lsm works better for writes

Also, won't most of the lib be removed due to dead code elimination? And used code will be inlined where applicable, so nothing to dedup in reality

Rust can set restricts to all pointers, because 1 mut xor many shared refs rule. Borrow checker empowers this. https://en.wikipedia.org/wiki/Restrict

What the point, though? You will get compiling code, but later you would need to reachitecture code to avoid violating rust rules.

It takse long to regen on big codebases, but yes