Memory leak detected

[jkomyno]

Preliminary note. I didn't installed inflight directly, it's just a package that glob uses.

$ npm list inflight
myLibrary@0.0.1 path/to/myLibrary
`-- glob@7.1.2
  `-- inflight@1.0.6

I'm developing a CLI apps that scans a set of files in the user's disk. Sometimes, it stops working throwing the following log:

<--- Last few GCs --->

[7828:000001CAE9906BF0]      729 ms: Mark-sweep 27.1 (94.3) -> [...] allocation failure GC in old space requested
[7828:000001CAE9906BF0]      754 ms: Mark-sweep 27.1 (94.3) -> [...]  last resort
[7828:000001CAE9906BF0]      780 ms: Mark-sweep 27.1 (32.3) -> [...] last resort


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 000002CEAE928799 <JSObject>
    1: _readdirEntries [path\to\myLibrary\node_modules\glob\glob.js:~559] [pc=000002F43C32198C](this=0000001978260B49 <Glob map = 000000777A7EB871>,abs=0000027C3514ED71 [...]

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

So, I've inspected the Node's process' heap usage (node --inspect myLibrary.js) and got the following result, in which the inflight module is the most expensive package in terms of retained size.

[Good-man]

Is this still an issue? I see that a fix was merged but the issue is still open.

[tysoncadenhead]

Can this issue be closed if it's been merged? I'd love to get the warning out of our security scanner

[ramdaniAli]

using npm-force-resolutions doesn't fundamentally resolve the issue since running npm ls glob may still show that the old, vulnerable version of the glob package is present in your dependency tree. A more robust solution is to leverage the overrides feature in your package.json. By explicitly specifying an override for glob, like this:

{
  ...
  "overrides": {
    "glob": "10.3.10"
  },
  ...
}

You ensure that the specified version of glob is applied throughout your project. However, for this approach to take effect, you will need to perform a fresh installation, you should delete the node_modules folder and the package-lock.json file, and then run npm install. This process forces npm to reinstall all dependencies, taking into account the override you've specified for glob. After doing this, Snyk should no longer report any warnings related to glob, confirming that the chosen version is now in use without any remnants of the old version.

[rreeves8]

using npm-force-resolutions doesn't fundamentally resolve the issue since running npm ls glob may still show that the old, vulnerable version of the glob package is present in your dependency tree. A more robust solution is to leverage the overrides feature in your package.json. By explicitly specifying an override for glob, like this:

{

  ...

  "overrides": {

    "glob": "10.3.10"

  },

  ...

}

You ensure that the specified version of glob is applied throughout your project. However, for this approach to take effect, you will need to perform a fresh installation, you should delete the node_modules folder and the package-lock.json file, and then run npm install. This process forces npm to reinstall all dependencies, taking into account the override you've specified for glob. After doing this, Snyk should no longer report any warnings related to glob, confirming that the chosen version is now in use without any remnants of the old version.

This isn't a robust solution either. Overriding dependency versions can create instability. Each package version is not exactly the same and changing it for every use case will most likely break stuff.

[ramdaniAli]

Certainly, overriding a sub dependency versions carries inherent risks, such as the introduction of unpredictable behavior or a destabilization of system components. Despite these concerns, in my specific situation where glob functions solely as a dependent of argon2, the associated risks are somewhat contained and manageable. At present, our most prudent course of action would be to remain vigilant for updates issued by the argon2 maintainers, in the hope that they will provide a comprehensive solution to the dependency concern.

[davidguilherme]

Glob package has a breaking change from version 8.x (latest with inflight) to 9.x (first without it). They changed its API to use promises instead of callbacks. I believe the best approach is to patch 8.x version to stop using inflight which will make a lot easier to override it in the package.json.

[MandeeGit]

we are seeing the same issue in checkmarx as well. is this false positive?

CWE-772

[bholmesACR]

Any status on a potential fix for this vulnerable package? We dont understand why there hasn't been a fix deployed for this risk yet. Please update us!

[kburns-r7]

Any status on a potential fix for this vulnerable package? We dont understand why there hasn't been a fix deployed for this risk yet. Please update us!

@bholmesACR last commit to this repo was 2 years ago. It seems to have been abandoned.

[isaacs]

I have no intention of working on this. I don't use it in or recommend it, and life is too short.

I just deprecated it, and I'll archive this repo shortly.

The language provides a lot of options nowadays for managing promises, which are a much better approach than callbacks in this sort of situation. If you want something that will coalesce async actions for the same key, then the lru-cache module provides this in a much more comprehensive way, using the fetchMethod function.