hacnho/tensorrt-disentangledattention-factor-bypass-poc

TensorRT DisentangledAttention factor bypass proof of concept

This repository contains a bounded research PoC for TensorRT (.engine / .trt / .mytrtfile).

The security question is whether a normal engine load path will accept a serialized DisentangledAttention_TRT state carrying factor = 2.0 even though the normal ONNX/plugin-create path rejects that same value with:

Validation failed: factor > 0.F && factor < 1.F

Files

• control.engine
• factor-two.engine
• factor-two-rejected.onnx
• verify_remote_poc.py

What the files demonstrate

factor-two-rejected.onnx:

• goes through the normal ONNX/plugin-create path
• is rejected during parse/build because factor = 2.0 violates the creator contract

factor-two.engine:

• loads via runtime.deserialize_cuda_engine(...)
• executes via engine.create_execution_context() and execute_async_v3(0)
• silently rescales attention output relative to control.engine

Control output prefix:

[0.03, 0.035, 0.04, 0.045, ...]

Serialized factor = 2.0 output prefix:

[0.6, 0.7, 0.8, 0.9, ...]

Verify the public HF artifacts

After unauthenticated download, run:

python verify_remote_poc.py

Expected result:

• factor-two-rejected.onnx is rejected in the normal creator path
• both .engine files still load successfully
• both .engine files still execute successfully
• factor-two.engine produces a different output prefix from control.engine
• deserialize_bypass_observed is true

Public scan note

After upload, check the public scan API:

https://huggingface.co/api/models/hacnho/tensorrt-disentangledattention-factor-bypass-poc/scan

For a scanner-bypass claim, the important signal is:

{"scansDone": true, "filesWithIssues": []}

This PoC itself is centered on trusted load/inference behavior, not on code execution.

Safety note

This is a bounded research PoC:

• no code execution claim
• no external callbacks
• only deterministic output rescaling after a trusted TensorRT engine load