binary vulnerability analysis of nvinfer.dll in TensorRT 8.6

[chky1997]

Description

Hi, I'm facing a problem when nvinfer.dll passing binary vulnerability analysis. The nvinfer.dll is downloaded from the zipfile from your website. Could you please tell me how to solve the problem? Or should I re-compile tensorrt by myself and replace the mentioned packages to avoid the problem? Thank you! The reports are below.

Environment

TensorRT Version: 8.6

Relevant Files

https://nvd.nist.gov/vuln/detail/CVE-2018-12886 https://nvd.nist.gov/vuln/detail/CVE-2019-15847 https://nvd.nist.gov/vuln/detail/CVE-2019-17543 https://nvd.nist.gov/vuln/detail/CVE-2023-45853

[zerollzeng]

Could you please explain what is your use case and what do you want to do? Sorry I don't quite get the report. Thanks!

[chky1997]

Thank you for your reply! I am currently planning to use TensorRT to build a c++ project. I simply download TensorRT from your official website and use nvinfer.dll to run my codes. I am asked to firstly pass the binary vulnerability analysis, in order to make sure the binary files I use are safe. However, the analysis report shows that there are several vulnerabilities found in nvinfer.dll. And specific details of the vulnerabilities are provided in Relevant Files. So I want to ask if these vulnerabilities will be solved later or is there any evidence to prove that these vulnerabilities are reported wrongly. Thank you!

[zerollzeng]

• @nvpohanh @oxana-nvidia for viz

[oxana-nvidia]

@chky1997 Could you please point to the issues specific to TensorRT? I don't see any in the provided logs. From your logs I see issues in zlib, lz4, gcc, opensuse_leap. Non in this list is maintained by TensorRT team.

Also, TensorRT is not an open source code, I'm not sure what you want to re-compile.

[chky1997]

@oxana-nvidia Thank you for your help! As far as I know, the vulnerability logs I provided show that those third party packages may be outdated or proved unsafe. And these third party packages are used for building nvinfer.dll. Therefore, if I want nvinfer.dll pass the binary vulnerability analysis, its third party dependencies should be safe.

Sorry for the expression about re-compiling. I mean one solution may be re-building TensorRT and replace the third-party packages with their latest versions, in order to get a safe nvinfer.dll. However, I'm not sure about that because I notice that TensorRT do not use those packages as third party directly. So I need your help for seeking out which part of TensorRT needs those packages and how to solve the problem.

Thank you!

[oxana-nvidia]

@chky1997 TensorRT 8.6 is a relatively old version (your build is from April 2023 based on the log). When that build was created zlib 1.2.13 was up to date version (1.3 was released in August 2023). I would expect newer versions of TensorRT to use zlib 1.3. You can try for example TensorRT 9.2 (which comes with TensorRT-LLM). (lz4 and opensuse_leap are related to it, I believe)

For gcc compiler, we are considering to move to a newer version. I would expect TensorRT 9.2 to use gcc 9. But we can not switch to gcc 13 straightforward as there are limitations from OS and different compilation requirements from our dependencies and configurations we need to support. What is a minimum gcc version that can pass your vulnerability analysis?

[chky1997]

Thank you for your advice. I notice that TensorRT 9.2 can not be downloaded from (https://developer.nvidia.com/tensorrt-download). Could you please help me with that?

[zerollzeng]

TRT 9 is a limited release so we didn't put it in dev zone. How ever it can be downloaded from below links.

https://developer.nvidia.com/downloads/compute/machine-learning/tensorrt/9.2.0/tensorrt-9.2.0.5.linux.x86_64-gnu.cuda-11.8.tar.gz https://developer.nvidia.com/downloads/compute/machine-learning/tensorrt/9.2.0/tensorrt-9.2.0.5.linux.x86_64-gnu.cuda-12.2.tar.gz https://developer.nvidia.com/downloads/compute/machine-learning/tensorrt/9.2.0/tensorrt-9.2.0.5.ubuntu-22.04.aarch64-gnu.cuda-12.2.tar.gz

[chky1997]

So there isn't a windows release?

[zerollzeng]

Correct.

[ttyio]

I will close this since from the comment, the warning is throw from components that not controlled by TRT like zlib, lz4. Thanks all!