deps: V8: backport f320600cd1f4 (V18.x CVE-2024-4761)
V8 Backport of https://github.com/v8/v8/commit/f320600cd1f48ba6bb57c0395823fe0c5e5ec52e
Fixes CVE-2024-4761, which has been tagged by CISA as KEV.
Review requested:
- [ ] @nodejs/gyp
- [ ] @nodejs/security-wg
- [ ] @nodejs/v8-update
Any reason to believe this is needed? wasm-gc has not been enabled in V8 until very recently (end of 2023)
Latest Node 18 minor version has V8 10.2.154.26. See https://github.com/nodejs/node/blob/v18.20.4/deps/v8/include/v8-version.h CVE-2024-4761 fixed in V8 version 12.6.213 by https://github.com/v8/v8/commit/f320600cd1f48ba6bb57c0395823fe0c5e5ec52e Hence the need for a backport.
My point is that wasm-gc (the feature that the commit targets), was not enabled in V8 10.2. So that version cannot be affected.
@mcollina this doesn't even build. I'm sorry but I refuse to spend voluntary time fixing stuff for broken payed security tools.
@giancorderoortiz I appreciate the effort you made, this is not your fault
I'd also like to understand something: let's say that we successfully (and meaningfully) backport a V8 CVE fix into v18.x. What mechanism will make the security tools stop flagging Node.js as vulnerable?
I'm sorry but I refuse to spend voluntary time fixing stuff for broken payed security tools.
As said, this is up to @giancorderoortiz and their employer to fix if they want to, not us.
(So no, don't spend any time on it @targos).
What mechanism will make the security tools stop flagging Node.js as vulnerable?
I actually have no clue. Likely they can put a checkmark in a spreadsheet that this was mitigated. It is the unfortunate reality of the enterprise world.
If any of my current or past employers would have needed something like this under a support contract, I would have obliged, to the point of sending a PR or creating a build of Node just for them.
Frankly, dealing with these kind of things is why we are enrolling in HeroDevs.
I'm one of the few active releasers. Creating a release is a lot of time.
We should also take into account the risk of backporting V8 fixes. This very pull request shows that it is non trivial and while here it's obvious because the build is broken, another change might build fine but break the system in unexpected ways. I don't know if anyone in the active collaborator base knows V8 good enough to properly review these changes
I can't find the issue atm, but I recall that @RafaelGSS mentioned he would assemble a release.
CI: https://ci.nodejs.org/job/node-test-pull-request/62127/
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=rhel8-ppc64le,v8test=v8test/6181/
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=rhel8-s390x,v8test=v8test/6181/
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=benchmark-ubuntu2204-intel-64,v8test=v8test/6181/
CI: https://ci.nodejs.org/job/node-test-pull-request/62243/
The outcome of the TSC meeting is that, unfortunately, we are not planning to accept this backport due to compatibility risk as this will need to go to maintenance release.
Thanks anyway.