hacnho/tensorrt-reorg-stride-bypass-poc

TensorRT Reorg_TRT serialized-stride bypass PoC

This repository contains a bounded security research PoC for a TensorRT model file vulnerability in .engine artifacts.

Files:

• control-stride2.engine
• reorg-patch-neg1.engine
• reorg-patch-3.engine
• reproduce.py
• SHA256SUMS.txt

What the files demonstrate:

• control-stride2.engine uses the normal serialized stride = 2.
• reorg-patch-neg1.engine changes only the serialized stride field to -1.
• reorg-patch-3.engine changes only the serialized stride field to 3.

All three files still load through:

trt.Runtime(...).deserialize_cuda_engine(...)
engine.create_execution_context()
ctx.execute_async_v3(0)

Expected behavior:

• control-stride2.engine returns the normal rearranged tensor.
• reorg-patch-neg1.engine still executes with copy_rc = 0, but silently corrupts the tensor rearrangement.
• reorg-patch-3.engine still executes with copy_rc = 0, but heavily suppresses the rearranged output.

Reproduction:

python reproduce.py --gpu 0

If CUDA libraries are not on the default loader path, set LD_LIBRARY_PATH first. Example from the validation lab:

LD_LIBRARY_PATH=/home/hacnho/.venv-vllm/lib/python3.12/site-packages/nvidia/cu13/lib:$LD_LIBRARY_PATH python reproduce.py --gpu 0

Expected delta summary:

control first16:
[0.0, 2.0, 4.0, 6.0, 16.0, 18.0, 20.0, 22.0, 32.0, 34.0, 36.0, 38.0, 48.0, 50.0, 52.0, 54.0]

neg1 first16:
[0.0, 0.0, 0.0, 0.0, 4.0, 3.0, 2.0, 1.0, 8.0, 7.0, 6.0, 5.0, 12.0, 11.0, 10.0, 9.0]

stride3 first16:
[0.0, 3.0, 6.0, 9.0, 36.0, 39.0, 42.0, 45.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

The key security point is that creator-invalid serialized stride values still produce successful runtime execution and finite output tensors instead of being rejected at engine load time.