Executive Summary

This vulnerability exists in the ONNX-MLIR compiler's placeholder node cache handler. Specifically, the lightweight hashing path used to generate cache keys for placeholder nodes only included the tensor shape but omitted the data type (dtype). This caused models with the same structure and shape but different data types (e.g., float32 vs. float64) to generate identical cache keys.

As a result, when a second model with a different dtype but the same shape was run, it would reuse the compiled shared object (.so) file from the first model, leading to incorrect inference results without any error or warning.

The vulnerability is due to the use of a weak hash key that does not uniquely identify models differing by dtype. The fix involves modifying the cache key generation to include the dtype by appending it to the placeholder node's identifier, ensuring unique cache keys for models with different dtypes.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can cause incorrect inference results when running ONNX models through the ONNX-MLIR compiler. If two models have the same shape but different data types, the second model may silently reuse the compiled code of the first model due to identical cache keys.

This silent reuse leads to inaccurate outputs without any error or warning, potentially compromising the reliability and correctness of machine learning model predictions.

The attack requires local access and is considered difficult to exploit due to high complexity.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability is related to the use of a weak hash in the generate_hash_key function of the ONNX-MLIR compiler's placeholder node cache handler. Detection involves verifying if the affected version of onnx-mlir (up to 0.5.0.0) is in use and if the system is locally running models that might reuse compiled shared objects incorrectly due to the weak hash.

Since the issue is local and related to the software version and its behavior, detection can be done by checking the installed ONNX-MLIR version and reviewing if the patch (commit 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4) has been applied.

Suggested commands to detect the vulnerable version and patch status include:

• Check ONNX-MLIR version: `onnx-mlir --version` or check the installed package version via your package manager.
• Search for the presence of the patch commit in the source code repository if built from source: `git log -p | grep 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4`
• Monitor inference results for inconsistencies when running models with identical shapes but different data types, which may indicate the weak hash issue.

Useful 0 Not Useful 0

Mitigation Strategies

The primary mitigation step is to apply the patch identified by commit 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4, which fixes the weak hash by including the data type in the cache key generation.

If you are using a version of ONNX-MLIR up to 0.5.0.0, update to a version that includes this patch or manually apply the patch if building from source.

Since exploitation requires local access and is complex, restricting local access to trusted users and environments can reduce risk.

Additionally, validate inference results especially when running multiple models with similar shapes but different data types to detect any anomalies.

Useful 0 Not Useful 0

Compliance Impact

The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.

Useful 0 Not Useful 0