package/localedef: build issue with old glibc (<= 2.38)
While building host-localedef from glibc 2.38 sources, it uses the
features.h header from its sources that define _ISOC2X_SOURCE 1 as
soon as _GNU_SOURCE is defined.
_ISOC2X_SOURCE enable __GLIBC_USE_ISOC2X 1 that enable the header
redirection to use __isoc23_* functions introduced in glibc 2.38 [1].
If an older version is installed on the host, those functions
doesn't exist and break the build.
Add a local patch to keep _ISOC2X_SOURCE and __GLIBC_USE_ISOC2X
disabled.
Enable mathvec explicitly on aarch64(be) since it's now enabled by
default [1]. aarch64 mathvec requires at gcc-10 but Buildroot already
provide gcc-11 as minimum version.
Don't use --enable-fortify-source for now in order to keep original
behavior while doing the glibc version bump (and because some
architecture doesn't support well fortify-source, i.e Microblaze).
Postpone this change to a follow up commit.
Keep the "deprecated" libcrypt enabled just in case if some
application are not yet ready to use an alternative such as libxcrypt.
Security related changes:
CVE-2023-25139: When the printf family of functions is called with a
format specifier that uses an <apostrophe> (enable grouping) and a
minimum width specifier, the resulting output could be larger than
reasonably expected by a caller that computed a tight bound on the
buffer size. The resulting larger than expected output could result
in a buffer overflow in the printf family of functions.
Runtime tested with Qemu on Gitlab-ci:
https://gitlab.com/kubu93/buildroot/-/pipelines/998435203
https://gitlab.com/buildroot.org/toolchains-builder/-/pipelines/998926028
- Switch to cmake-package as autotools has been removed since version
9.0.0
- This bump will fix the following build failure with gcc 13 thanks to
https://github.com/OSGeo/PROJ/pull/3459/commits/b0b8937c56ced8eb0ffef532b9c691a1a5fc8634:
In file included from proj_json_streaming_writer.cpp:34:
proj_json_streaming_writer.hpp:42:14: error: 'int64_t' in namespace 'std' does not name a type
42 | typedef std::int64_t GIntBig;
| ^~~~~~~
package/libvpx: Add upstream security patch to fix CVE-2023-5217
Fixes CVE_2023-5217: Heap buffer overflow in vp8 encoding in libvpx in
Google Chrome prior to 117.0.5938.132 and libvpx 1.13.1 allowed a remote
attacker to potentially exploit heap corruption via a crafted HTML page.
Small improvements to on-screen use only. CLI -B and GUI 'B' to toggle
boxes around stats. CLI -^ and '^' to change units for Disk I/O KB/s ->
MB/s -> GB/s. This happen temporarily too if the size of the statistic
will not fit on-scree. Code changed to ensure clean compile for GCC 12
which does extra checks but got confused by some perfectly good C code!
Note: updated makefile makefile
/home/buildroot/autobuild/run/instance-2/output-1/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-buildroot-linux-gnu/12.3.0/../../../../mipsel-buildroot-linux-gnu/bin/ld: stress-crypt.o: in function `$L17':
stress-crypt.c:(.text+0x2dc): undefined reference to `crypt_r'
All of these are quite simple to figure out programmatically based on the
content of BINARIES_DIR, so extend post-image.sh to fall back to generating
a genimage configuration based on genimage.cfg.in if a board specific one
does not exist.
- Fix CVE-2023-35852: In Suricata before 6.0.13 (when there is an
adversary who controls an external source of rules), a dataset
filename, that comes from a rule, may trigger absolute or relative
directory traversal, and lead to write access to a local filesystem.
This is addressed in 6.0.13 by requiring allow-absolute-filenames and
allow-write (in the datasets rules configuration section) if an
installation requires traversal/writing in this situation.
- Fix CVE-2023-35853: In Suricata before 6.0.13, an adversary who
controls an external source of Lua rules may be able to execute Lua
code. This is addressed in 6.0.13 by disabling Lua unless allow-rules
is true in the security lua configuration section.
- Drop first patch (not needed since
https://github.com/OISF/suricata/commit/c8a3aa608eaae1acbaf33dba8a7c1a3cbfeb4285)
Fix CVE-2023-38633: A directory traversal problem in the URL decoder of
librsvg before 2.56.3 could be used by local or remote attackers to
disclose files (on the local filesystem outside of the expected area),
as demonstrated by href=".?../../../../../../../../../../etc/passwd" in
an xi:include element.
The COPYING also contains a BSD-3-Clause license. The BSD-3-Clause
applies to "manual page unifdef.1 and the portability support code in
the FreeBSD subdirectory". The BSD-2-Clause applies to everything else.
Commit 84c24ab1b5a7 (package/nodejs: fix parallel build) made use of
BR2_JLEVEL to set the number of jobs nodejs should use instead of using
the number of CPUs (+2).
However, BR2_JLEVEL can be set to 0 by the user, to let Buildroot detect
the number of CPUs (+1), and stores it in PARALLEL_JOBS, and leaves
BR2_JLEVEL untouched, so 0.
Thus, we can end up spawning a build by passing -j0 to ninja, which it
interprets as "no -limit yolo" and does not limit the number oj jobs it
spawns, which usually ends up in an OOM somewhere...
- Drop second and third patches (already in version)
- C++ is mandatory since
https://github.com/urcu/userspace-rcu/commit/153b081a9b007aad7bece415dc3bf1125edd2da3
- Fix CVE-2023-26916: libyang from v2.0.164 to v2.1.30 was discovered to
contain a NULL pointer dereference via the function lys_parse_mem at
lys_parse_mem.c.
- Fix CVE-2023-26917: libyang from v2.0.164 to v2.1.30 was discovered to
contain a NULL pointer dereference via the function
lysp_stmt_validate_value at lys_parse_mem.c.
Fix CVE-2023-3341: The code that processes control channel messages sent
to `named` calls certain functions recursively during packet parsing.
Recursion depth is only limited by the maximum accepted packet size;
depending on the environment, this may cause the packet-parsing code to
run out of available stack memory, causing `named` to terminate
unexpectedly. Since each incoming control channel message is fully
parsed before its contents are authenticated, exploiting this flaw does
not require the attacker to hold a valid RNDC key; only network access
to the control channel's configured TCP port is necessary. This issue
affects BIND 9 versions 9.2.0 through 9.16.43, 9.18.0 through 9.18.18,
9.19.0 through 9.19.16, 9.9.3-S1 through 9.16.43-S1, and 9.18.0-S1
through 9.18.18-S1.
- Drop patches (already in version) and so drop autoreconf
- Update hash of BSD_LICENSE (update in year:
https://github.com/hreinecke/sg3_utils/commit/551657bfbf3b571a7b8ca6e489a407cb22eab387)
- Drop all patches (already in version)
- Update hash of LICENSE file (year updated with
https://github.com/Cyan4973/xxHash/commit/f035303b8a86c1db9be70cbb638678ef6ef4cb2d)
When nodejs is build, a qemu wrapper script is used to execute some
programs built for the target in user-mode emulation. However, when the
target and build machines are similar (e.g. x86_74), running those
programs fails, with errors such as:
cd ../../tools/v8_gypfiles; python ../../deps/v8/tools/run.py ../../out/Release/v8-qemu-wrapper ../../out/Release/bytecode_builtins_list_generator ../../out/Release/obj.host/gen/generate-bytecode-output-root/builtins-generated/bytecodes-builtins-list.h
../../out/Release/bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ../../out/Release/bytecode_builtins_list_generator)
../../out/Release/bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ../../out/Release/bytecode_builtins_list_generator)
../../out/Release/bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ../../out/Release/bytecode_builtins_list_generator)
../../out/Release/bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ../../out/Release/bytecode_builtins_list_generator)
Return code is 1
So the question is: why the heck does Qemu use the host C library?
To answer this question, we first have to look at how the -L option of
Qemu is implemented. This option is documented as such:
-L path QEMU_LD_PREFIX set the elf interpreter prefix to 'path'
The v8-qemu-wrapper script makes this option point to $(STAGING_DIR),
so that the ELF interpreter used is the one in $(STAGING_DIR).
However, contrary to what the option documentation says, this option
does much more than setting the ELF interpreter prefix: it is going to
affect how *all* system calls manipulating files (open, etc.) are
going to work.
When this option is passed, the function init_paths() in
https://git.qemu.org/?p=qemu.git;a=blob;f=util/path.c is called at
initialization time, and essentially its sets the global "base"
variable to point to the directory passed as -L argument.
Then, for every single syscall that manipulates a path, this path will
be passed through the path() function in the same file. This function
will first attempt to resolve the path with "base" as a prefix, and if
not, return the unprefixed path.
After adding some traces into this function, I was able to understand
what happens:
(1) -L$(STAGING_DIR) is passed, causing "base" to point to
$(STAGING_DIR)
(2) The target ELF interpreter from $(STAGING_DIR) is properly invoked
(3) When this ELF interpreter then resolves the libc.so.6 library, it
first looks for /etc/ld.so.cache.
(4) Qemu first looks for /etc/ld.so.cache with the -L prefix, i.e
$(STAGING_DIR)/etc/ld.so.cache, but it does not exist. So, the Qemu
system call emulation falls back to /etc/ld.so.cache, which means
the target ELF interpreter reads the /etc/ld.so.cache of the host
system.
(5) This /etc/ld.so.cache of the host system says that libc.so.6 is in
/lib/x86_64-linux-gnu/
(6) The target ELF interpreter therefore tries to use
/lib/x86_64-linux-gnu/libc.so.6. The Qemu system call emulation
first tries $(STAGING_DIR)/lib/x86_64-linux-gnu/libc.so.6, but
this library does not exist (it is in
$(STAGING_DIR)/lib/libc.so.6), so the Qemu system call emulation
falls back to /lib/x86_64-linux-gnu/libc.so.6 of the host system,
which exist... but is too old compared to the target C library.
Indeed, results from ld.so.cache take precedence over the simple
resolution of library paths in /usr/lib and /lib.
We see 3 possible ideas to resolve this problem:
(A) Change the behavior of Qemu to not fallback to unprefixed paths:
when -L is passed, all path-related system calls should see the
paths prefixed by the -L option.
Issue with this is that this change is unlikely to get accepted by
Qemu upstream. And there might be some side effects we have not
really identified.
(B) Create an empty $(STAGING_DIR)/etc/ld.so.cache. We have tested
this solution and it works: it gets used instead of the host
/etc/ld.so.cache. Because $(STAGING_DIR)/etc/ld.so.cache is empty,
there's no libc.so.6 match, so the target ELF interpreter goes
through its normal library location resolution logic, which falls
back to trying in /usr/lib and /lib, which works as those paths
ends up being prefixed with $(STAGING_DIR) by Qemu.
(C) Pass LD_LIBRARY_PATH pointing to $(STAGING_DIR)/lib and
$(STAGING_DIR)/usr/lib in the Qemu wrapper. This works because
LD_LIBRARY_PATH paths have precedence over paths given by
ld.so.cache.
This is the solution already used by the GOI qemu wrapper in
package/gobject-introspection/g-ir-scanner-qemuwrapper.in.
We chose to go with the third option, because it has been proven to work
for the GOI wrapper, and has been reported to solve #14366. Even though
the first option would be the best, it is also the one that has the
least chances to land any time soon (if ever); the second has not been
exercised, and the impact is not fully understood either (e.g what about
non-glibc toolchains?).
- Drop patch (already in version)
- Drop license comment and add REAMDE and libopeniscsiusr/COPYING as
license files due to
https://github.com/open-iscsi/open-iscsi/commit/10d50ed4bcf9ef6820f7fe544df0c3605ea4144f
composefs/libcomposefs/lcfs-writer-erofs.c:37:10: fatal error: linux/fsverity.h: No such file or directory
37 | #include <linux/fsverity.h>
| ^~~~~~~~~~~~~~~~~~
Unless told otherwise, ninja will spawn as many jobs as there are CPU
(plus 2). Nodejs is built with ninja, but it is a generic package, so
there is no variable (like with cmake-package) that passes the proper
number of parallel jobs as configured by the user.
As a consequence, the nodejs build will use as many CPU as are
available, possibly overcommitting the rsources the user expected to be
used.
package/nut: package/nut: specify --with-user/group when building NUT
This commit fixes a problem where the NUT package couldn't be
used as a NUT server due to the fact that the default group for
nobody is "nogroup" and not "nobody" like the internal default
of NUT. Thus, when starting a NUT server daemon the daemon starts
with incorrect group permissions. This commit fixes this
shortcoming by introducing a dedicated 'nut' user and 'nut' group
to drop priviledges to it.
For release announce, see:
https://lists.infradead.org/pipermail/kexec/2023-August/027830.html
This new version introduced a usage of memfd_create() in [1]. This
function was introduced in Kernel 3.17. Therefore, this commit adds
this new dependency. This direct use of memfd_create() requires a
glibc >= 2.27. As is, this version would no longer work with uclibc-ng
or musl libc. This commit also adds a patch to allow compilation with
glibc < 2.27, and also uclibc and musl. See the patch commit log for
more details.
The CPE entry for this CVE is
cpe:2.3:a:libssh:libssh:-:*:*:*:*:*:*:*
We interpret the "-" as matching any version. It actually means
"unspecified version", which is the cop-out in case there is nothing
useful to match. We can't really make our infrastructure ignore "-"
entirely, because for all we know our version is an unreleased commit
sha which _is_ vulnerable. Thus, the only way out is an exclusion which
we'll never be able to remove.
Allow enabling support for both the X11 and Wayland backends.
This in turn needs reorganizing how desktop GL or OpenGL ES is chosen,
as it no longer can depend on whether Wayland support is enabled: the
BR2_PACKAGE_HAS_LIBGL and BR2_PACKAGE_HAS_LIBGLES variables are both
checked, and ENABLE_GLES2 is set only if the package providing OpenGL
claims only GLES is supported; otherwise desktop GL is preferred. This
matches the existing logic.
The existing comment indicating that only one of both windowing systems
can be enabled was wrong: the same WebKitGTK build can target both
X11 and Wayland at the same time, as long as GTK itself has been built
accordingly. Enabling both is the approach taken by most Linux
distributions, and has been supported for years.
Thomas Devoogdt [Sat, 9 Sep 2023 07:57:50 +0000 (09:57 +0200)]
package/webkitgtk: security bump to version 2.40.5
Bugfix release with many security fixes, including (but not limited to)
patches for CVE-2023-37450, CVE-2023-38133, CVE-2023-38572, CVE-2023-38592,
CVE-2023-38594, CVE-2023-38595, CVE-2023-38597, CVE-2023-38599,
CVE-2023-38600, and CVE-2023-38611.
docs/manual: add section to explain how to give credits to a sponsor
Sometimes it happens that a Company or a Physical Person sponsors the
creation and/or the upstreaming process of a patch, but at the moment
there is no way to give credits to it. In Linux they prepend '+sponsor'
to the e-mail of the contributor in both authorship and commit log tag as
discussed here[0]. So let's describe in the manual how to do that as a
standard.
Signed-off-by: Giulio Benetti <[email protected]>
[[email protected]:
- reword to reference sub-addressing and the RFC
- move to the "submitting patches" section, that already deals with
SoB tags
- differentiate between Your/Their names
] Signed-off-by: Yann E. MORIN <[email protected]>
projects / buildroot.git / log