Skip to content

doc: add constraints for mem leak to threat model #58917

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

RafaelGSS
Copy link
Member

doc: add constraints for mem leak to threat model

As discussed in https://github.com/nodejs-private/node-private/pull/719.

We should clarify what the criteria are to accept
memory leak as a vulnerability (potential DoS).

cc: @nodejs/tsc @nodejs/security-wg

As discussed in nodejs-private/node-private#719.

We should clarify what the criteria are to accept
memory leak as a vulnerability (potential DoS).

Signed-off-by: RafaelGSS <[email protected]>
@RafaelGSS RafaelGSS added security Issues and PRs related to security. security-wg-agenda labels Jul 1, 2025
@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/tsc

@RafaelGSS RafaelGSS changed the title ddoc: add constraints for mem leak to threat model doc: add constraints for mem leak to threat model Jul 1, 2025
@nodejs-github-bot nodejs-github-bot added the doc Issues and PRs related to the documentations. label Jul 1, 2025
* Memory leaks qualify as vulnerabilities when all of the following criteria are met:
* The API is being correctly used
* The API doesn't have a warning against its usage in a production environment
* The API is on stable (2.0) status
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* The API is on stable (2.0) status
* The API is public and documented
* The API is on stable (2.0) status

* The API is being correctly used
* The API doesn't have a warning against its usage in a production environment
* The API is on stable (2.0) status
* The memory leak is significant, causing a DoS fast or in a user-uncontrolled space (for instance, on HTTP parsing)
Copy link
Member

@joyeecheung joyeecheung Jul 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel that we still need more restrictions to avoid flagging all the existing memory leaks as vulnerabilities just because they weren't reported as vulnerabilities (for example, #54614 probably satisfies all the criteria and it can be used in server handlers). As long as a buggy API is used in the wrong place, it can cause a DoS fast, and it doesn't have to be a memory leak, so it seems to be a very slippery slope.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations. security Issues and PRs related to security. security-wg-agenda
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants