| Title | ModelCloud GPTQModel <= 7.1.0 Out-of-Bounds Read |
|---|
| Description | GPTQModel's Triton dequantization kernel reads out of bounds when loading a crafted GPTQ checkpoint.
GPTQ checkpoints that use activation reordering carry a per-row group index tensor called g_idx. When a checkpoint is loaded, its g_idx overwrites the layer buffer and is never revalidated. The Triton layer's post_init has its g_idx regeneration commented out, so the values from the file reach the kernel unchanged.
In gptqmodel/nn_modules/triton_utils/dequant.py the kernel derives a group index from g_idx applying only a negative-wrap adjustment, with no upper bound. It then indexes scales at position col_idx plus out_features multiplied by groups, and the matching qzeros entry. The bound it would need, num_groups, is itself read from the checkpoint as scales.shape[0]. A g_idx value at or above num_groups indexes both arrays past their extent. The result is an out-of-bounds GPU read that crashes the CUDA context and can expose adjacent device memory.
The Torch backend performs the same gather through bounds-checked PyTorch indexing and faults safely, so only the Triton path is affected.
Confirmed on GPTQModel 7.1.0 using compute-sanitizer on an NVIDIA A100. An unmodified checkpoint runs clean. A checkpoint whose g_idx exceeds num_groups produces the out-of-bounds read.
Exploitation requires the victim to load an untrusted checkpoint. It is not reachable with a legitimate model.
Fixed by pull request 2950, merged 2026-07-14, which bound-checks the checkpoint g_idx. |
|---|
| Source | ⚠️ https://github.com/ModelCloud/GPTQModel/issues/2949 |
|---|
| User | m00dy (UID 97162) |
|---|
| Submission | 07/27/2026 00:07 (1 month ago) |
|---|
| Moderation | 09/06/2026 17:40 (1 month later) |
|---|
| Status | Accepted |
|---|
| VulDB entry | 399447 [ModelCloud GPTQModel up to 7.2.0 Triton dequantization kernel tritonv2.py g_idx out-of-bounds] |
|---|
| Points | 20 |
|---|