提交 #906135: ModelCloud GPTQModel <= 7.1.0 Out-of-Bounds Read

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.

• 来源: ⚠️ https://github.com/ModelCloud/GPTQModel/issues/2949
• 用户: m00dy (UID 97162)
• 提交: 2026-07-27 00時07分 (1 月前)
• 管理: 2026-09-06 17時40分 (1 month later)
• 状态: 已接受
• VulDB条目: 399447 [ModelCloud GPTQModel 直到 7.2.0 Triton dequantization kernel tritonv2.py g_idx 信息公开]
• 积分: 20