Security implications of log4j in CUDA

Log4j was recently assigned a widely reported CVE vulnerability: CVE - CVE-2021-44228

CUDA drivers seem to contain an unpatched log4j version under

What is the impact of this dependency and will there be a security release of CUDA drivers?

[Security Notice: NVIDIA Response to Log4j Vulnerability (CVE-2021-44228) - December 2021 | NVIDIA]

I think they are working now…

1 Like

We deploy ML Models on Production using Tesla T4 and K80 GPUs. I have also found the existence of a similar file at /usr/local/cuda-11.2/libnvvp/plugins/org.apache.ant_1.9.2.v201404171502/lib/ant-apache-log4j.jar

Two questions:

  1. Why is CUDA using log4j? There should be some configuration file for configuring logging if logging is the answer.

  2. What version of Log4J is CUDA using? Most JARs have versions declared in the filename itself.

I think this is used in the cave-based performance profiler -but not in computing itself per se.

typo—in the java-based performance profiler

Our security and product teams are actively investigating this issue.

Please continue to monitor the Security Notice for the latest updates at:

Thank you for investigating the risks posed by this log4j vulnerability. The Security Notice linked does not (yet) explain the presence of the ant-apache-log4j.jar library in the CUDA library, nor inform us as to whether it presents a risk. When you get a chance, please update the Security Notice so those of us who use your CUDA library may properly understand our risk. Thank you!


+1 to the earlier comments.

We see /usr/local/cuda-11.2/libnvvp/plugins/org.apache.ant_1.9.2.v201404171502/lib/ant-apache-log4j.jar in our environment, and according to the Maven listing it looks like this version contains log4j-1.2.13.

This wouldn’t be affected by CVE-2021-44228 but it is affected by CVE-2019-17571, still a critical vulnerability.

Are there any plans or timelines in place to fix this issue?

Your comment about Maven is of interest. I was wondering about that --since I couldn’t tell from the jar files in the org.apache.ant_1.9.2 v201404171502/lib subdirectory. I agree this is likely of lesser risk. But I was concerned about comments about indirect exploits in the Carnegie Mellon analysis about lib4j 1.X: VU#930724 - Apache Log4j allows insecure JNDI lookups but ----we may be OK: VU#930724 - Apache Log4j allows insecure JNDI lookups

Essentially: Log4j 1.x does not have Lookups so the risk is lower. Applications using Log4j 1.x are only vulnerable to this attack when they use JNDI in their configuration. A separate CVE (CVE-2021-4104) has been filed for this vulnerability. To mitigate: audit your logging configuration to ensure it has no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability. -This is their analysis: I may be off base but doing a jar tvf on the *.jars under the apache lib subdirectory I don’t see JMSAppender class paths defined or any configuration files in the Nvidia install so: SUMMARY if JNDI is not used in the configuration and JMSAppender is not configured—I don’t think logging is going to occur–and the indirect vulnerability is not present. This is as far as I have gotten in my naive analysis. I will await word from NVIDIA postings. I do wonder why End of Life apache components are present in fairly recent NVIDIA-cuda releases. Presently I have chosen to delete the apache EOL components under the CUDA 10.1- CUDA 11.2 releases to sidestep the issue for the moment-as this does not affect GPU computing capability.

GRID vGPU license manager is reported to be affected by the 1.x vulnerability.
The fix is simple: replace the library with a fixed version and then restart the process.