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>
