Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I discovered cwe-416 vulnerability in my project. #1326

Closed
wants to merge 2 commits into from

Conversation

Jellybin06
Copy link

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.

I just want you to know that in the second case, this vulnerability appears due to continuous compilation errors.

Although it is not a major vulnerability and does not provide the best source code, I hope this helps.

@Jellybin06 Jellybin06 closed this Jan 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant