Pick patches as listed in NVD CVE report.
Note that Debian lists one of the patches as introducing the
vulnerability. This is against what the original report [1] says.
Also the commit messages provide hints that the first patch fixes this
issue and second is fixing problem with the first patch.
[1] https://jvn.jp/en/jp/JVN19358384/
(From OE-Core rev: a157719ab349d9393d5a640bb2e45fc2489d5338)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
ssh in OpenSSH before 10.1 allows control characters in usernames that
originate from certain possibly untrusted sources, potentially leading
to code execution when a ProxyCommand is used. The untrusted sources
are the command line and %-sequence expansion of a configuration file.
Note:
openssh does not support variable expansion until 10.0, so backport
adapts for this.
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2025-61984
Upstream patch:
35d5917652
(From OE-Core rev: 717d4c7609cdce2cc3a65b7ba69c316fa86a9333)
Signed-off-by: David Nyström <david.nystrom@est.tech>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
ssh in OpenSSH before 10.1 allows the '\0' character in an ssh:// URI,
potentially leading to code execution when a ProxyCommand is used.
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2025-61985
Upstream patch:
43b3bff47b
(From OE-Core rev: 52d925423b826383d12a97b834475ab5699fd492)
Signed-off-by: David Nyström <david.nystrom@est.tech>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
When Bash runs with 'set -u' (nounset), accessing an unset variable
directly (e.g. [ -z "$SSL_CERT_FILE" ]) causes a fatal "unbound variable"
error. As a result, the fallback logic to set SSL_CERT_FILE/SSL_CERT_DIR
is never triggered and the script aborts.
The current code assumes these variables may be unset or empty, but does
not guard against 'set -u'. This breaks builds in stricter shell
environments or when users explicitly enable 'set -u'.
Fix this by using parameter expansion with a default value, e.g.
"${SSL_CERT_FILE:-}", so that unset variables are treated as empty
strings. This preserves the intended logic (respect host env first, then
CAFILE/CAPATH, then buildtools defaults) and makes the script robust
under 'set -u'.
(From OE-Core rev: 4cf131ebd157b79226533b5a5074691dd0e1a4ab)
Signed-off-by: Haixiao Yan <haixiao.yan.cn@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 4d880c2eccd534133a2a4e6579d955605c0956ec)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Pick commits for Minerva fix between 3.2.4 and 3.2.5 release.
Update to 3.2.5 is blocked due to problem with python ptest errors, so
use patch instead of upgrade for now.
(From OE-Core rev: 57c04a32997c1b045121aff045f3ffaa7bb0b5f5)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
As discussed in [1], this commit fixes CVE-2024-41996.
Although openssl project does not consider this a vulnerability, it got
CVE number assigned so it deserves attention.
[1] https://github.com/openssl/openssl/pull/25088
(From OE-Core rev: cb49b9e49b4561ccea4c231cac591af557b9749c)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Set the permissions of /var/run/kea to 750 to fix kea server startup
error:
ERROR [kea-dhcp4.dhcp4/445.140718820303936] DHCP4_INIT_FAIL failed to
initialize Kea server: configuration error using file
'/etc/kea/kea-dhcp4.conf': 'socket-name' is invalid: socket
path:/var/run/kea does not exist or does not have permssions = 750
This permission check was introduced by commit[1] in kea 2.4.2.
[1] f7061c4e97
(From OE-Core rev: 5b709e2c165bf46f4f35e1783ab7ec54fabd2ec3)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Since Linux v2.4 it has been possible to stop all NFS server by running
rpc.nfsd 0
i.e. by requesting that zero threads be running. This is preferred as
it doesn't risk killing some other process which happens to be called
"nfsd".
Since Linux v6.6 - and other stable kernels to which
Commit: 390390240145 ("nfsd: don't allow nfsd threads to be
signalled.")
has been backported - sending a signal no longer works to stop nfs server
threads.
This patch changes the nfsserver script to use "rpc.nfsd 0" to stop
server threads.
(From OE-Core rev: 01fca40ba44070891518d4126a34d7c9c0939f6d)
Signed-off-by: NeilBrown <neil@brown.name>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 7b09ad289a36)
Signed-off-by: Haixiao Yan <haixiao.yan.cn@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Without this patch btmgmt will always use hci0 in
non interactive mode.
(From OE-Core rev: 45c50169fa7e34349acf3e24fc19e573cbab4e65)
Signed-off-by: Jeroen Hofstee <jhofstee@victronenergy.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
When not building with the default PACKAGECONFIG options, the build can fail
with:
undefined reference to `media_player_controller_create'
undefined reference to `media_player_set_status'
Otherwise. So disable it when not set and enable it by default.
The packageconfig option is the same as in Styhead.
ebbdb7cf5c (diff-9d9284f6f27a81c75dffffd6d601b40c8266ae12e678d0a49c46bdb8356a0e91R52)
(From OE-Core rev: 82448a6c8b720cefc200513daa41115961b43e8f)
Signed-off-by: Jeroen Hofstee <jhofstee@victronenergy.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
To adapt user network enviroment, buildtools should first try to use
the user configured envs like SSL_CERT_FILE/CURL_CA_BUNDLE/..., if these
envs is not set, then use the auto-detected ca file and ca path, and
finally use the CA certificates in buildtools.
nativesdk-openssl set OPENSSLDIR as "/not/builtin", need set SSL_CERT_FILE/SSL_CERT_DIR to work
nativesdk-curl don't set default ca file, need
SSL_CERT_FILE/SSL_CERT_DIR or CURL_CA_BUNDLE/CURL_CA_PATH to work
nativesdk-git actually use libcurl, and GIT_SSL_CAPATH/GIT_SSL_CAINFO
also works
nativesdk-python3-requests will use cacert.pem under python module certifi by
default, need to set REQUESTS_CA_BUNDLE
(From OE-Core rev: 0653b96bac6d0800dc5154557706a323418808be)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
* make git,curl,python3-requests align with openssl, move the setting of
envvars into respective envfile
* for environment.d-openssl.sh, also check if ca-certificates.crt exist
before export envvars
(From OE-Core rev: 5f4fd544d3df7365224599c9efdce4e545f51d5e)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Backport patch to remove vulnerable component.
This is a breaking change, but there will be no other fix for this CVE
as upstream did the deletion without providing a fix first.
If someone really needs this feature, which the commit message describes
as deprecated, bbappend with patch removal is possible.
License-Update: passprompt plugin removed
(From OE-Core rev: 5350ef531ded14f0b4c32c211aaf993354be1ec9)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This change will prevent these tools from being installed if the image doesn't install bluez5-noinst-tools package.
BlueZ 5.66: tools/mesh-tester
BlueZ 5.66: tools/ioctl-tester
BlueZ 5.65: tools/iso-tester
BlueZ 5.56: tools/btpclientctl
BlueZ 5.51: tools/bcmfw
BlueZ 5.49: tools/rtlfw
BlueZ 5.47: tools/btconfig (not a new tool, but it was moved from bin_PROGRAMS to noinst_PROGRAMS)
(From OE-Core rev: 87cadf62ba0d6b0fc3dc0151a5d320919b7eb1ab)
Signed-off-by: Guðni Már Gilbert <gudni.m.g@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Rewrite (again) the openssl test suite installation.
Depend on and reuse already installed libraries and modules instead of
installing them twice.
Be more selective when installing from the build tree so we don't install
intermediate .c .d .o files.
This further reduces the size of openssl-dbg from ~120MB to ~18MB.
(From OE-Core rev: 8baa0ce7eae65026cb3a784adaf3a4fc724ce9c9)
Upstream-Status: Backport[https://git.yoctoproject.org/poky/commit/?id=76212866402edb947f745f837e3c3b98b3056e58]
(From OE-Core rev: b3cd05f123625c4c301fee925cdbb9641bc73412)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 7621286640)
Signed-off-by: Vishwas Udupa <quic_vudupa@quicinc.com>
Change-Id: Ifc0e3a019c2abe5142d0f1e359ae5aa33dae1608
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled.
A machine-in-the-middle attack can be performed by a malicious machine impersonating
a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific
conditions when verifying the host key. For an attack to be considered successful,
the attacker needs to manage to exhaust the client's memory resource first, turning
the attack complexity high.
(From OE-Core rev: 60b5df194a5bea491489fdae2f32e33ffd21c9c7)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
sshd(8) in OpenSSH versions 9.5p1 to 9.9p1
(inclusive) is vulnerable to a memory/CPU denial-of-service related
to the handling of SSH2_MSG_PING packets. This condition may be
mitigated using the existing PerSourcePenalties feature.
Upstream-Status: Backport [6ce00f0c2e]
(From OE-Core rev: 7360f3998939e202f9611644a8bed0c3fe0c782a)
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
ppp version 2.5.0 fails to run properly if an expected /run/pppd/lock
directory does not exist, which is not usually created in a yocto
built OS.
Backport the patch from upstream version 2.5.1 that fixes the issue by
reverting back to /var/lock.
The related github issue upstream was:
"lock directory moved in ppp-2.5.0 #419" [1]
Link: https://github.com/ppp-project/ppp/issues/419
(From OE-Core rev: 0869eb50e39c567cc1d50db4eb287f02866196cf)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This reverts commit 49391fdcf71b32c5fd3c7b134c1d1c45cc1db388 which
introduced a bluetooth regression on systems with read-only rootfs.
When configuration files are missing, bluez tries to generate them which
fails on a read-only rootfs. As a result bluetooth service fails to
start and bluetooth is broken. Hence, configuration files need to be
installed in the rootfs in a way or another.
Bluez commit be0e79629 (build: ship all config files with --enable-datafiles,
2024-02-12) introduced configuration files installation in bluez version
5.73. However, scarthgap pulls in version 5.72, so it is responsible of the
installation of configuration files until bluez is upgraded. Scarthgap
commit 49391fdcf71b32c5fd3c7b134c1d1c45cc1db388 removed installation of
configuration files too early, hence the revert.
(From OE-Core rev: 54a7014a801ddbda2a7dfe1ab560a154064ad47e)
Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
With Linux kernel v6.6, due to commit 59b047bc9808 ("Bluetooth:
MGMT/SMP: Fix address type when using SMP over BREDR/LE"), an error
might occur when trying to automatically repair a bluetooth device, as
the key might store using a wrong/invalid address type. This happens
only with bluez5 version 5.72:
HCI Event: Link Key Request (0x17) plen 6 bdaddr 8C:98:6B:7A:BD:F0
HCI Command: Link Key Request Negative Reply (0x01|0x000c) plen 6 bdaddr 8C:98:6B:7A:BD:F0
This was already solved upstream, therefore backport the patch to fix
this issue.
(From OE-Core rev: d719d02f2f3ce8f54de0e10d89a8d389edb61fed)
Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Pick patch from branch openssl-3.2.
(From OE-Core rev: df9cd27e23f051fb02391ca62d29f152f36f76fe)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Picked patches according to
http://w1.fi/security/2024-1/hostapd-and-radius-protocol-forgery-attacks.txt
First patch is style commit picked to have a clean cherry-pick of all
mentioned commits without any conflict.
Patch CVE-2024-3596_07.patch has hostapd code removed as it is not
present in wpa-supplicant download tarball.
(From OE-Core rev: 2352c8a1282b7b11a542eb7a821625580c8395fa)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
NVD CVE report [1] links Ubuntu bug [2] which has a very good
description/discussion about this issue.
It applies only to distros patching wpa-supplicant to allow non-root
users (e.g. via netdev group) to load modules.
This is not the case of Yocto.
Quote:
So upstream isn't vulnerable as they only expose the dbus interface to
root. Downstreams like Ubuntu and Chromium added a patch that grants
access to the netdev group. The patch is the problem, not the upstream
code IMHO.
There is also a commit [3] associated with this CVE, however that only
provides build-time configuration to limit paths which can be accessed
but it acts only as a mitigation for distros which allow non-root users
to load crafted modules.
[1] https://nvd.nist.gov/vuln/detail/CVE-2024-5290
[2] https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/2067613
[3] https://w1.fi/cgit/hostap/commit/?id=c84388ee4c66bcd310db57489eac4a75fc600747
(From OE-Core rev: 33548479f66164f486efdb6aeba2de7da2b5b0c9)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
------C65ED3E1A5DE826CA595746785F6AF6F
To: openembedded-core@lists.openembedded.org
CC: Alban Bedel <alban.bedel@aerq.com>
Subject: [PATCH] bind: Fix build with the `httpstats` package config enabled
Date: Wed, 11 Sep 2024 08:26:47 +0200
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
MIME-Version: 1.0
When the `httpstats` package config is enabled configure fails with
the error:
> configure: error: Specifying libxml2 installation path is not
> supported, adjust PKG_CONFIG_PATH instead
Drop the explicit path from `--with-libxml2` to solve this issue.
(From OE-Core rev: b87811febbb1a33182d8a3eb8c0f671548ae999a)
Signed-off-by: Alban Bedel <alban.bedel@aerq.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 9b076fa51f5e6fd685066fb817c47239960778e6)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The solution to the problem upstream was fixed by the following commit:
ca6546fe52
Now MAX_INPUT is defined for non-glibc systems such as musl.
This fix was added in BlueZ 5.67.
(From OE-Core rev: a2532944258334c9f64b673278040dd5e27489d2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Guðni Már Gilbert <gudni.m.g@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Updated SRC_URI link and format due to change in openssl website.
CVE's Fixed by upgrade:
CVE-2024-5535: Fixed possible buffer overread in SSL_select_next_proto().
CVE-2024-6119: Fixed possible denial of service in X.509 name checks
- Removed backports of CVE-2024-5535 as it is already fixed.
- Removed first hunk of 0001-Added-handshake-history-reporting-when-test-fails.patch as the copyright years are already updated in test/helpers/handshake.c file
Detailed Information:
https://github.com/openssl/openssl/blob/openssl-3.2/CHANGES.md#changes-between-322-and-323-3-sep-2024
(From OE-Core rev: 2155e3016a98ae0db28488dcc5176437e6f8b24a)
Signed-off-by: Siddharth Doshi <sdoshi@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This version bump adds new features and should not have been taken.
This reverts commit 35c2b5f56bca789b9723a144fda0a130a67a860c.
(From OE-Core rev: 79ed0dba62404b9de3cd97bc861dea8779416afc)
Signed-off-by: Steve Sakoman <steve@sakoman.com>