Glonce

Voltage glitching unlocks A100 features on NVIDIA CMP 170HX mining card

securityThe Glonce editorsHacker News🔥76Glonce rating76Impact60Novelty75Relevance85Surprise75Players65Credibility85

A blog post reports a voltage fault injection (VFI) vulnerability on NVIDIA's GA100 die that lets an operator blow arbitrary fuses. The author says they used it to convert a CMP 170HX 8GB mining card into what is effectively an A100-80G. They also claim their unlocked cards run about 1.2x faster than a retail A100, because all functional SMs are enabled (about 120-126, depending on the die lottery) instead of the 108 SMs NVIDIA chose for every production A100. Features that the CMP line disables, namely NVLink, PCIe Gen4, NVJPG, NVDEC and MIG, are said to be unlockable the same way, though the author has not specifically tested NVJPG, NVDEC or MIG.

The core point is a design flaw in how NVIDIA uses fuses. They serve for product segmentation, security features and access control, and in several cases blowing a fuse grants more access, not less. The author argues that in a properly secured design a blown fuse should always make the chip more restrictive, since a blown fuse cannot be unblown in an economically feasible way. NVIDIA's design lets one relax restrictions by blowing more fuses.

Background: the GA100 has powered almost 20 SKUs, the A100 being the best known. As fabbed it has 128 SMs, 12 FBPs (framebuffer partitions, two per HBM stack), 5 NVDEC units and a PCIe Gen4 x16 controller, with 4-6 HBM stacks depending on framebuffer size. eFuses turn undifferentiated dies into more restricted variants based on defect testing and demand. In one extreme case, the CMP 170HX Ethereum mining card, with nominally 8 or 10 GB of application-exposed framebuffer, actually carries about 80 and about 40 GB of HBM respectively. The post is about fully unlocking that capacity. Earlier work, including research by Jon Pry and others, had already unlocked much of the GA100 through software; VFI is described as the last mile.

The fuse controller holds 16,384 eFuses (512 rows of 32) and turns them into "option words" that decide what the die does. The post splits them into four regions. Regular fuses (rows 0-221) map to option words, often with a primary and a redundant copy, and once blown there is basically no way to unblow them except through RIR. Fuseless fuses, or FF (rows 222-487), encode effective option words in a JTAG-chain-like format; NVIDIA reportedly built this after accidentally blowing regular fuses and ruining engineering samples. IFF fuses (rows 487-512, as the post writes the range) use a different instruction format, are out of scope, and are usually not accessible on a production card. RIR fuses (8 rows of 32, outside the 512) are the fuse macro designer's repair mechanism, with room for 16 repair instructions. On the 8 GB 170HX, 15 of the 16 words are all ones and the 16th is a repair instruction of little use for unlocking. The 10 GB SKU is different, but the author leaves that for another day.

FF is where most of the unlockable functionality lives. Each FF row is a 32-bit record: bits 0-4 pick a chain, bit 5 distinguishes FF from IFF, bits 6-15 pick a 16-bit block, and bits 16-31 hold the block's new value. If two records address the same chain and block, the later one wins. So appending a record can clear an effective bit set by an earlier one without unblowing any physical fuse. This works for FF-backed options but not for the control fuses in rows 0 and 1, which hold security-sensitive option words. Under normal conditions NVIDIA strictly prevents FF fuse blows. The mappings from FF chains and blocks to option words were found by a researcher who cross-compared FF values and effective option words across GA100 SKUs; there is no known official mapping.

The author's idea is to write FF rows that set the _DISABLE option words to all zeroes, or as permissive as die defects allow, which stops parts of the die from being floorswept (made unreachable and likely powered down). The author believes, from experiments, that floorsweep lines are specified in RTL, run from the fuse controller to individual blocks, and respond with very little latency to the effective status words. A worked example on one 8 GB card: OPT_FBP_DISABLE was 0x852, masking FBPs 1, 4, 6 and 11, while the separate OPT_FBP_DEFECTIVE mask was 0x840, covering 6 and 11. After a replacement FF row reduced the disable mask to 0x840, the masks on 1 and 4 were gone and those FBPs, which had refused register reads and writes, became responsive. FBPs 6 and 11 stayed disabled, leaving 10 of the 12.

Unfloorsweeping alone is not enough, because the default framebuffer geometry uses only part of each HBM stack. The author therefore adapts cmpunlocker's driver patch, the usual 8 to 64 GB unlock, which writes feature configuration words such as FBPA_CFG and SM_SPEED_SELECT. With the FF burns in place, more permissive values can be written, giving what is functionally an A100-80G.

The remaining question is how to blow FF fuses at all. Fuse blows are requested through the FUSEADDR, FUSEWDATA and FUSECTRL registers. They are not nominally reachable by the host or unprivileged requesters, but the author says opening the privilege masks is trivial using the "Canary in the Crypto Mine" ROP. Researchers have tried to coerce the controller into blowing FF-region fuses and shared some observations: it has an internal state machine reported via FUSECTRL_STATE bits, and it enters a WRITE_PROGRAM state for each hot bit in FUSEWDATA. The post then notes that, unless a specific option word is cleared, writes to fuse addresses outside the FPF range are blocked, and VFI is the technique used to defeat those safeguards. If arbitrary FF fuses could be blown, the author says, any GA100 could be unlocked to its maximum capability, as set by die yield and the populated memory stacks.

The author says the findings were disclosed to NVIDIA's product security team before publication, and that they publish now because another security researcher independently found the same vulnerability; they consider publication to be in the public interest.

Key facts

  • The author reports a voltage fault injection vulnerability on NVIDIA's GA100 die that allows blowing arbitrary fuses, and says it turned a CMP 170HX 8GB mining card into what is effectively an A100-80G.
  • The author's own claim: unlocked cards run about 1.2x faster than a retail A100, with about 120-126 SMs enabled (die-lottery dependent) versus the 108 SMs on every production A100.
  • The flaw is architectural: on NVIDIA dies some blown fuses grant more access, and the fuseless-fuse (FF) region works as a script where a later 32-bit record overrides an earlier one, so option words can be cleared without unblowing anything.
  • Software alone is not enough: the author also adapts cmpunlocker's driver patch so the framebuffer geometry uses the full HBM stacks. The CMP 170HX 8 GB and 10 GB cards carry about 80 and 40 GB of HBM respectively.
  • The findings were disclosed to NVIDIA's product security team before publication; the author publishes now because another researcher independently found the same vulnerability.

Why it matters

NVIDIA sells one GA100 die as many products, from a datacenter A100 to a mining-only CMP card, and fuses draw the lines between them. The author says that boundary can be crossed by physically glitching the chip's voltage so that extra fuses blow. Earlier public work had unlocked parts of the die through software, such as cmpunlocker's 8 to 64 GB driver patch; the post describes VFI as the missing last step. The author also argues that letting blown fuses relax restrictions is improper for a secured design, which is the part that goes beyond a hobbyist unlock.

Who it affects

Owners of CMP 170HX cards are the direct beneficiaries: the 8 GB model reportedly carries about 80 GB of HBM and the 10 GB model about 40 GB. NVIDIA is affected because its fuse-based segmentation and access control are the thing being bypassed. The author also says that if arbitrary FF fuses could be blown, any GA100 could be unlocked to its maximum capability, limited by die yield and populated memory stacks, so the point reaches beyond one card.

How to use it

The post is research, not a ready recipe. The part available here covers the background an attempt would need: the fuse controller layout, the 32-bit FF record format, the option words for floorsweeping, and a modified cmpunlocker driver patch that writes more permissive values to registers such as FBPA_CFG and SM_SPEED_SELECT after the FF burns. The glitching setup itself (hardware, timing, voltages, success rate) is not described in the text this retelling is based on. The author says the 10 GB SKU is different and leaves it for another day.

How solid is it

This is a single researcher's first-person report, backed by a concrete worked example: the FBP mask going from 0x852 to 0x840, with FBPs 1 and 4 starting to respond to register reads and writes. The 1.2x speed figure and the A100-80G equivalence are the author's own claims, and no benchmark method or results are given in the available text. The author builds on prior work by Jon Pry and others, and says another researcher independently found the same vulnerability. The FF-to-option-word mappings come from a researcher cross-comparing SKUs, since there is no known official mapping, and the floorsweep wiring is the author's belief from experiments. The primary post is only partly available, so the glitching procedure itself could not be checked.

Risks and caveats

Blown fuses cannot be unblown in an economically feasible way, and the post notes that NVIDIA itself ruined engineering samples by accidentally blowing regular fuses, so mistakes are likely permanent. The author has not tested NVJPG, NVDEC or MIG unlocking. FF-based overrides do not work for the control fuses in rows 0 and 1. Unfloorswept blocks are not fully usable without the driver-side configuration change. Die defects still limit results: in the worked example FBPs 6 and 11 stayed disabled, and the SM count depends on the die lottery. No CVE, NVIDIA response, patch or statement is mentioned in the available text.

“NVIDIA’s design allows one to relax restrictions by blowing more fuses!”

— From the post's summary