Hello Malayke 👋
You have submitted this pull request as a bug bounty report in the github/securitylab repository and therefore this pull request has been put into draft state to give time for the GitHub Security Lab to assess the PR. When GitHub Security Lab has finished assessing your pull request, it will be marked automatically as Ready for review. Until then, please don't change the draft state.

In the meantime, feel free to make changes to the pull request. If you'd like to maximize payout for your this and future submissions, here are a few general guidelines, that we might take into consideration when reviewing a submission.

• the submission models widely-used frameworks/libraries
• the vulnerability modeled in the submission is impactful
• the submission finds new true positive vulnerabilities
• the submission finds very few false positives
• code in the submission is easy to read and will be easy to maintain
• documentation is written clearly, highlighting the impact of the issue it finds and is written without grammatical or other errors. The code samples clearly show the vulnerability
• the submission includes tests, change note etc.

Please note that these are guidelines, not rules. Since we have a lot of different types of submissions, the guidelines might vary for each submission.

Happy hacking!

Are you aware of the existing query go/ql/src/Security/CWE-190/AllocationSizeOverflow.ql? This seems very closely related. Can you comment on whether they overlap?

I carefully read the code of AllocationSizeOverflow. If I understand correctly, AllocationSizeOverflow restricts the input of the source to the Marshal function, and the query focuses on whether there will be an overflow.

According to my testing, when the make slice is very large and exceeds the maximum value, it will trigger a panic error, but the program will continue to run normally and not cause denial of service. If it does not exceed the maximum value, the program will run normally but consume a large amount of memory. In this case, the program will exhaust the memory resources, leading to denial of service.

The query I wrote specifically checks whether the size of the make slice is directly defined by an untrusted source. From the results of the two queries, it seems that AllocationSizeOverflow cannot detect the vulnerabilities of the two CVEs I mentioned.