The NEON SIMD fast path in the bundled llhttp calls
__builtin_ctzll(match_mask) without checking if match_mask is zero.
When all 16 bytes in a NEON register are valid header value characters,
match_mask is 0. Calling __builtin_ctzll(0) is undefined behavior.
GCC at -O2 exploits this by optimizing "if (match_len != 16)" to
always-true, causing HTTP 400 Bad Request for any header value longer
than 16 characters on ARM targets with NEON enabled.
Fix by explicitly checking for match_mask == 0 and setting
match_len = 16. This bug affects both aarch64 and armv7 NEON targets.
The code this patch modifies is generated, so the patch itself isn't
suitable for upstream submission, as the root cause of the error is
in the generator itself. The fix has been merged upstream[1] in
llparse 7.3.1 and is included in llhttp 9.3.1. This patch can be
dropped when nodejs updates its bundled llhttp to >= 9.3.1.
[1]: https://github.com/nodejs/llparse/pull/83
Signed-off-by: Telukula Jeevan Kumar Sahu <j-sahu@ti.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The llhttp vendored dependency of nodejs takes advantage of Arm NEON
instructions when they are available, however they are detected by
checking for an outdated CPU feature macro: it checks for __ARM_NEON__,
however it is not defined by new compilers for aarch64, rather they
set __ARM_NEON. The Arm C extension guide[1] refers to __ARM_NEON macro
aswell.
This patch changes the detection to check for both macros when detecting
the availability of NEON instructions.
The code this patch modifies is generated, so the patch itself isn't
suitable for upstream submission, as the root cause of the error is
in the generator itself. A PR has been submitted[2] to the generator
project to rectify this issue.
[1]: https://developer.arm.com/documentation/ihi0053/d/ - pdf, section 6.9
[2]: https://github.com/nodejs/llparse/pull/84
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The llhttp dependency of nodejs uses NEON intrinsics when they
are available, however some of these calls are incorrect: they
the call they use don't match the parameters passed, and so
the compilation fail (unless the error is suppressed):
| ../deps/llhttp/src/llhttp.c: In function 'llhttp__internal__run':
| ../deps/llhttp/src/llhttp.c:2645:9: note: use '-flax-vector-conversions' to permit conversions between vectors with differing element types or numbers of subparts
| 2645 | );
| | ^
| ../deps/llhttp/src/llhttp.c:2643:11: error: incompatible type for argument 1 of 'vandq_u16'
| 2643 | vcgeq_u8(input, vdupq_n_u8(' ')),
There is a patch upstream that fixes it (though it is not merged
yet). This patch is a port of that fix.
This allows us to remove the extra CFLAGS also from the recipe that
suppressed this error.
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
In case nghttp2 and/or libuv PACKAGECONFIGs are enabled, nodejs
will build some binaries for the build system also, linking to
native binaries and using headers from the native sysroot.
However in case the dependencies are missing from the native sysroot,
then it falls back to the build system's sysroot, and use the files
that it can find there. If the build system doesn't have nghttp2/libuv
installed, then compilation fails:
libuv:
../tools/executable_wrapper.h:5:10: fatal error: uv.h: No such file or directory
ngtthp2:
<...snip...>/build/tmp/hosttools/ld: cannot find -lnghttp2: No such file or directory
To avoid falling back to the build system's sysroot, add the missing
libuv-native and nghttp2-native dependencies.
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This patch isn't intended to introduce new behavior, rather it
changes the order of some existing LDFLAGS to fix a workaround that
stopped working at some point in the past.
LDFLAGS:x86 contains libatomic, because linking with this library
is required for this platform.
However when gyp links, it invokes the following (pseudo-)command:
$LD $LDFLAGS $RESOURCES_TO_LINK $EXTRA_LIBS $EXTRA_LDFLAGS
The EXTRA* arguments are coming from the gyp config. Since
LDFLAGS appears very early in the command, libatomic also
appears early amongst the resources, and the linker couldn't
find the relevant symbols when compiled for x86 platform (as
it was processed the very last):
| [...] undefined reference to `__atomic_compare_exchange'
Using this patch the library appears at the end, along with
the other EXTRA_LIBS, after the list of linked resources,
allowing linking to succeed.
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Fixes:
ERROR: nodejs-22.21.1-r0 do_patch: Applying patch '0001-deps-disable-io_uring-support-in-libuv.patch' on target directory '/build/tmp/work/core2-32-poky-linux/nodejs/22.21.1/sources/node-v22.21.1'
CmdError('quilt --quiltrc /build/tmp/work/core2-32-poky-linux/nodejs/22.21.1/recipe-sysroot-native/etc/quiltrc push', 0, "stdout: Applying patch 0001-deps-disable-io_uring-support-in-libuv.patch
can't find file to patch at input line 27
The sources which related to libuv as deps/uv/ are removed in prune_sources
when depends on libuv.
So postpone prune_sources execute at do_patch phase to fix the gap.
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This is the December 2025 security release that the nodejs team released
January 13, 2026.
3 high severity issues.
4 medium severity issues.
1 low severity issue.
High priority fixes:
CVE-2025-55131
CVE-2025-55130
CVE-2025-59465
Medium priority fixes:
CVE-2025-59466
CVE-2025-59464
CVE-2026-21636 *
CVE-2026-21637
Low priority fixes:
CVE-2025-55132
* note that this medium priority CVE only effects Nodejs v25.
https://nodejs.org/en/blog/vulnerability/december-2025-security-releases
Changelog: https://github.com/nodejs/node/releases/tag/v22.22.0
Signed-off-by: Jason Schonberg <schonm@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
CVE_PRODUCT is specified twice - the second instance only duplicates one
value from the first instance.
Remove this extra CVE_PRODUCT.
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Use gcc to compile failed for 32 bit arm target
$ echo 'MACHINE = "qemuarm"' >> conf/local.conf
$ bitbake nodejs
...
2645 | );
| ^
../deps/llhttp/src/llhttp.c:2643:11: error: incompatible type for argument 1 of 'vandq_u16'
2643 | vcgeq_u8(input, vdupq_n_u8(' ')),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| uint8x16_t
...
Use '-flax-vector-conversions' to permit conversions between vectors
with differing element types or numbers of subparts
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
When clang is used as cross compiler, it confuses gyp
system to enable -m64 option for host pieces of build
and the reason is that it assumes clang to be biarch
by default for all architectures but that maybe true for
x86/x86_64 combo but not true for arm/aarch64 systems
This is a backport from node 24
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Plenty of other recipes inherit qemu unconditionally, including
some pretty foundational ones like python3, and they do not need
this fix. I think something else is going on here, and that issue
needs to be properly investigated.
There's a request to provide steps to observe the issue, but the original
patch author so far hasn't been able to reproduce it on demand:
https://lists.openembedded.org/g/openembedded-devel/topic/113861973
This reverts commit b2a950a75b15c93f625bfe6514bc248c9310813f.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The recipe unconditionally inherits the qemu class, because it executes
some target binaries when it is cross-compiled and the bit-width of the
build host and the target host are different.
Since it is unconditional, it also means that it is inherited for native
and nativesdk builds also. The qemu class uses some qemu options that are
always derived from the target machine's configuration, even when the
recipe is built for class-native. This means that some of the variables
used by the recipe changes (e.g. QEMU_OPTIONS), and the shared state cache
is invalidated when the target machine changes, even when nodejs-native is
being built - and it triggers a full rebuild of nodejs-native unnecessarily.
To avoid this, inherit the qemu class conditionally, only in case it is
used (when the target and build arch's bit-widths are different).
Also, inherit qemu-native based on the same condition, and move around the
qemu-dependent code a bit, so it will be only executed when the qemu class
is inherited.
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Please see
https://git.yoctoproject.org/poky/commit/?id=4dd321f8b83afecd962393101b2a6861275b5265
for what changes are needed, and sed commands that can be used to make them en masse.
I've verified that bitbake -c patch world works with these, but did not run a world
build; the majority of recipes shouldn't need further fixups, but if there are
some that still fall out, they can be fixed in followups.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This reverts commit 24ff52ba3b73757cc0255a5b19822e2e4d3d4e0a.
The original patch was my bad. The patches for oe-core were re-worked,
but I forgot the recall this patch.
In fact, inheriting qemu is needed because it sets a clear barriar
for people to use qemu user mode. And the QEMU_OPTIONS settings
are also in qemu.bbclass.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Avoid inheriting qemu.bbclass and use oe.qemu.xxx instead.
Also, the 'qemu-native' dep is replaced by 'qemuwrapper-cross' for
PACKAGE_WRITE_DEPS. qemuwrapper-cross is the one that is actually
used by postints and it has 'qemu-native' in DEPENDS.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Brotli can crash nodejs (on ARM), because the memory allocated for
brotli wasn't properly aligned.
https://github.com/google/brotli/issues/1159dc035bbc9b
Signed-off-by: Jeroen Hofstee <jhofstee@victronenergy.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This moves us from the previous Long Term Support version codenamed 'Iron' to the newly
released Long Term Support version 22.11.0 Codename 'Jod'
Changelog: https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V22.md#22.11.0
License-Update:
Add amaro dependency under MIT License.
Add swc dependency under Aapche License Version 2.0.
Add simdjson dependency under Apache License Version 2.0.
Add on-exit-leak-free under MIT License.
Remove ESLint.
Remove base64 dependency.
Removed patchs:
182d9c05e78.patch - This was a backport to 20.x it is now integrated in 22.x
Added patches:
Two small patches here to use Bourne Shell instad of BASH.
0001-custom-env.patch
0001-positional-args.patch
This patch from https://github.com/nodejs/node/commit/686da19abb that addressed CVE-2024-22017
0001-deps-disable-io_uring-support-in-libuv.patch
Other patches were refreshed.
Signed-off-by: Jason Schonberg <schonm@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Drop two patches which haven't been referenced by the nodejs recipe since the
20.11.0 version checkin.
0001-build-fix-build-with-Python-3.12.patch
0001-gyp-resolve-python-3.12-issues.patch
Signed-off-by: Jason Schonberg <schonm@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
As noted in the libc++ 19 release notes [1], std::char_traits<> is now
only provided for char, char8_t, char16_t, char32_t and wchar_t, and any
instantiation for other types will fail.
This causes nodejs-20 to fail to compile with clang 19 and libc++ 19,
resulting in errors similar to:
/usr/include/c++/v1/string:820:42: error: implicit instantiation of undefined template 'std::char_traits<unsigned short>'
820 | static_assert(is_same<_CharT, typename traits_type::char_type>::value,
| ^
../deps/v8/src/inspector/string-16.h:114:28: note: in instantiation of template class 'std::basic_string<unsigned short>' requested here
114 | std::basic_string<UChar> m_impl;
| ^
/usr/include/c++/v1/__fwd/string.h:23:29: note: template is declared here
23 | struct _LIBCPP_TEMPLATE_VIS char_traits;
| ^
Upstream v8 has fixed this in commit 182d9c05e78 [2], so add it as a
backported patch, until the next version of node is released.
[1] https://libcxx.llvm.org/ReleaseNotes/19.html#deprecations-and-removals
[2] https://chromium.googlesource.com/v8/v8.git/+/182d9c05e78
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Due to the scope of supported BSPs by qemu-user is limited, such
as a segment fault on armv9 after qemu apply commit [target/arm:
Convert LDAPR/STLR (imm) to decodetree][1]
```
|tmp-glibc/work/neoversen2-crypto-wrs-linux/nodejs/20.5.1/node-v20.5.1/out/
Release/v8-qemu-wrapper.sh: line 7: 3179613 Segmentation fault (core dumped)
PSEUDO_UNLOAD=1 qemu-aarch64 -r 5.15 -L tmp-glibc/work/neoversen2-crypto-wrs-linux/
nodejs/20.5.1/recipe-sysroot -E LD_LIBRARY_PATH=tmp-glibc/work/neoversen2-crypto-wrs-linux/
nodejs/20.5.1/recipe-sysroot/usr/lib64:tmp-glibc/work/neoversen2-crypto-wrs-linux/
nodejs/20.5.1/recipe-sysroot/usr/lib64 "$@"
```
Upstream nodejs have cross compile support, but it needs host and target
have same bit width (e.g. a x86_64 host targeting arrch64 to produce a
64-bit binary). So:
1. If host and target have different bit width, build with QEMU user as usual;
2. If host and target have same bit width, enable notejs cross compile support:
- The build tools of nodejs is GYP[2], set CC_host, CFLAGS_host,
CXX_host, CXXFLAGS_host, LDFLAGS_host, AR_host for host build
which is separated with target build [3]
- Satisfy layer compatibility, set GYP variables in prefuncs of do_configure,
do_compile and do_install other than in recipe parsing
- Add missing native packages to fix library missing on host build
- Rework libatomic.patch, explicitly link to libatomic for clang
conditionally
[1] 2521b6073b
[2] https://github.com/nodejs/node-gyp
[3] https://github.com/nodejs/node-gyp/blob/main/gyp/docs/UserDocumentation.md#cross-compiling
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
* oe-npm-cache is now in UNPACKDIR not WORKDIR
* fixes:
http://errors.yoctoproject.org/Errors/Details/771012/
/OE/build/oe-core/tmp-glibc/work/x86_64-linux/nodejs-oe-cache-native/20.13/temp/run.do_configure.1268826: line 142: /OE/build/oe-core/tmp-glibc/work/x86_64-linux/nodejs-oe-cache-native/20.13/oe-npm-cache: No such file or directory
* set S and UNPACKDIR to avoid this as well:
WARNING: nodejs-oe-cache-native-20.13-r0 do_unpack: nodejs-oe-cache-native: the directory ${WORKDIR}/${BP} (/OE/build/oe-core/tmp-glibc/work/x86_64-linux/nodejs-oe-cache-native/20.13/nodejs-oe-cache-20.13) pointed to by the S variable doesn't exist - please set S within the recipe to point to where the source has been unpacked to
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Apparently, npm has changed its request accept header, so that cache
lookup misses. This causes an ENOTCACHED error when doing the offline
install in do_compile() from npm.bbclass.
Fix it by updating the fake cache entry to match the newest behaviour
from npm.
Note that npm doesn't agree with itself, as it still uses the previous
header value when doing `npm cache add <pkg>`, but the new value when
doing `npm install <pkg>`.
Bug submitted upstream:
https://github.com/npm/cli/issues/7465
Signed-off-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The original idea was always disable io_uring to avoid follwing failure
even when UV_USE_IO_URING is set to true, refer [1][2]:
0608: try:
*** 0609: update_hash(" %10s" % pwd.getpwuid(s.st_uid).pw_name)
0610: update_hash(" %10s" % grp.getgrgid(s.st_gid).gr_name)
0611: except KeyError as e:
0612: msg = ("KeyError: %s\nPath %s is owned by uid %d, gid %d, which doesn't match "
0613: "any user/group on target. This may be due to host contamination." %
Exception: Exception: KeyError: 'getpwuid(): uid not found: 20561'
But since 20.11.1, for fix CVE-2024-22017, io_uring is disabled by
default, refer [3]. So maybe patch
0001-deps-disable-io_uring-support-in-libuv.patch is not needed.
For case UV_USE_IO_URING is set to true, user can fix above failure
by "chown root:root -R ${D}" in do_install.
[1] https://lists.openembedded.org/g/openembedded-devel/message/105583
[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15244
[3] 686da19abb
[4] https://nvd.nist.gov/vuln/detail/CVE-2024-22017
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Drop patches for revert io_uring support in libuv:
0001-Revert-io_uring-changes-from-libuv-1.46.0.patch
0002-Revert-io_uring-changes-from-libuv-1.45.0.patch
Change to just always disable io_uring in libuv, in this way, we don't have to
pick out io_uring related changes and revert them when internal libuv
upgraded.
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
