cwe-416 vulnerability discovered and fixed #1324
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
hello. I am interested in your project and have analyzed the source code. We apologize for arbitrarily building the source code and testing for vulnerabilities. I ran about 40 vulnerability scans and found 2 vulnerabilities in the header file and 1 vulnerability in the cpp file.
Among these, static analysis was performed using codeql to analyze the cpp file. As a result, the cwe-416 vulnerability appeared in the path "/JUCE/modules/juce_audio_processors/format_types/VST3_SDK/public.sdk/source/vst/hosting/module_linux.cpp".
The results of cwe-416 found two loopholes. The first one was found in lines 167 to 168 of the existing source code. In the code, I am using a variable called stem to change the extension of the file to ".so" and then adding that stem to the modulePath. At this time, changes to stem are also reflected in modulePath. This means that the contents of the existing stem may be lost when creating a new path. This may lead to memory leaks or unsafe memory manipulation. To keep your code safe, you should perform appropriate validation before memory manipulation on stem or other important variables.
The second loophole is that the variable named filename is retrieved and used from a temporary object, and the problem occurs because this temporary object goes out of scope and is no longer valid in memory. In code 326, the Snapshot::decodeUID function uses filename, which can be problematic if filename is retrieved from a temporary object. You need to make sure that there is a reference to filename within this function. If the decodeScaleFactor function in code 330 also references filename, using that reference after the temporary object's lifetime has expired may cause problems. By modifying your code, you can safely access the data associated with filename even after the temporary object's lifetime has ended.
Although it is not a major vulnerability and does not provide the best source code, I hope this helps.