[v24.x] deps: patch npm/tar to not return uninitialized mem

[ChALkeR]

This goes against the npm update procedure but we don't have much time before LTS to revert zero-filling to wait for isaacs/node-tar#446, tar and npm releases

An alternative is to force .alloc instead of .allocUnsafe there

Refs:

• allocUnsafe is useless since 24 #60423
• 2025-10-28, Version 24.11.0 'Krypton' (LTS) #60414
• fix: do not return uninitialized memory isaacs/node-tar#446
• Race condition leading to uninitialized memory exposure isaacs/node-tar#445
• isaacs/node-tar@5330eb0
• security: Fix js/file-system-race (CWE-367) security issue isaacs/node-tar#444

[nodejs-github-bot]

Review requested:

• @nodejs/security-wg

[github-actions]

Fast-track has been requested by @nodejs-github-bot. Please 👍 to approve.

[aduh95]

Shouldn't we apply this diff also to

node/deps/corepack/dist/lib/corepack.cjs

Lines 15506 to 15508 in 82fc81c

	const buf = Buffer.allocUnsafe(stat.size);
	import_node_fs.default.readSync(fd, buf, 0, stat.size, 0);
	p.end(buf);

[ChALkeR]

@aduh95 this PR targets 24.x branch.
The problematic code in corepack did not get into 24.x

[aduh95]

If main also has the same problematic code, why not land the fix there instead of v24.x-staging?

[ChALkeR]

@aduh95 is there a reason to bypass the regular procedure in main?
Depends on when would isaacs/node-tar#446 be landed, if soon we could just update it as a regular dep.
24.x has the whole #60423 issue and is scheduled for LTS now

[ChALkeR]

@aduh95 also pls fell free to retarget this to the correct branch / force-push to my branch, I'm out of context of the staging branches

[aduh95]

is there a reason to bypass the regular procedure in main?

The regular procedure is for changes to first land upstream, then it can be cherry-picked to main, then to the vXX.x-staging branch of Current release, then be backported to LTS further after being in Current for two weeks. IIUC you're suggesting that we follow that procedure to main and v25.x, and this PR is a shortcut for v24.x only, correct?
In that case, do we want to take the shortcut? I mean, if v24.x is wrongfully zero-filling the buffer, the code is fine for the time being, no?

[ChALkeR]

do we want to take the shortcut?

Only if we we want to merge the non zero-filling behavior to 24 asap.
This PR was made to unblock that specifically

It's not needed otherwise

[ChALkeR]

See #60012 (comment)

I also rechecked the usage (so it was now checked by 2 people), npm does not use the vulnerable codepath
This can be closed, patching npm>tar is a non-blocker