Imagine you're a locksmith and someone files down one tooth on your key blank — just enough that the key still opens the door, but now you have to jiggle it every single time. The door opens, nothing looks broken, but every entry takes longer. That's the core mechanism here: a single bit-flip during compilation produces a GPU kernel that computes the right answer via a slower path, and because Triton caches compiled kernels to disk, that slowdown persists indefinitely across every subsequent inference call. The paper introduces LLVMhammer, which the authors call the first Rowhammer attack targeting LLM inference performance rather than correctness. The attack surface is Triton's MLIR/LLVM-based JIT compilation pipeline — the same pipeline OpenAI's Triton uses to generate fused GPU kernels for attention, matrix multiplication, and other hot ops. A Rowhammer-induced bit-flip in a performance-critical optimization pass (think: loop unrolling decisions, tiling parameters, register allocation) causes the compiler to emit a functionally equivalent but suboptimal kernel. Because Triton's target-independent stages are shared across GPU vendors, the attack is vendor-agnostic — demonstrated on both NVIDIA RTX 4090 and AMD RX 7900 XTX. To automate discovery of exploitable bit-flip locations, the authors build Karnage, a fuzzing-style tool that systematically flips bits across Triton's target-independent compilation passes and measures whether the resulting kernel is (a) still correct and (b) measurably slower. This is the methodological contribution that makes the attack practical rather than theoretical — manual inspection of LLVM IR to find performance-degrading-but-correctness-preserving bit-flips would be prohibitive. The evaluation spans four 7-8B parameter LLMs — Qwen2.5-7B-Instruct, Llama-3.1-8B-Instruct, Mistral-7B-Instruct-v0.3, and Deepseek-llm-7B-chat — and measures latency inflation on a single-GPU inference server. The headline number: 4-16% latency increase, which at multi-GPU datacenter scale translates to meaningful additional annual operating costs. The authors also demonstrate a more aggressive variant that corrupts outputs entirely, dropping BERTScore to as low as 25%, but the stealth-slowdown variant is the more interesting threat model because it evades functional correctness checks. The integrity picture is mixed. The evaluation is same-team simulation on real hardware, which is better than pure software simulation but far from an independent red-team exercise. The baseline comparison is straightforward — unmodified Triton vs. bit-flipped Triton — and the 4-16% range is plausible but not independently verified. There's no pre-registration, no community benchmark for this attack class (because none exists yet), and no code release is mentioned. The choice to test across two GPU vendors and four LLMs adds breadth, but the single-GPU evaluation leaves open how the slowdown compounds in tensor-parallel or pipeline-parallel multi-GPU setups. The broader significance is less about Rowhammer specifically — which requires physical proximity or co-tenancy — and more about the supply-chain fragility of JIT compilation for ML inference. Triton is becoming the default compilation target for high-performance LLM serving. Any persistent corruption of its cached kernels, whether via Rowhammer, supply-chain tampering, or a compromised CI pipeline, produces a degradation that is invisible to correctness-based monitoring. The paper's real contribution is naming this attack surface and demonstrating it is exploitable, not proving that Rowhammer is the most likely delivery mechanism. What's missing is the economic modeling: the paper gestures at 'additional annual operating costs at multi-GPU scale' but doesn't commit to a dollar figure or a model of how 4-16% latency inflation translates through queuing theory to actual throughput loss and cost. The successor experiment — testing on multi-GPU deployments with realistic load patterns — is conspicuous by its absence, likely because the authors had access to single-GPU setups only.