curl's websocket code did not update the 32 bit mask pattern
for each new outgoing frame as the specification says. Instead
it used a fixed mask that persisted and was used throughout
the entire connection.
A predictable mask pattern allows for a malicious server to induce
traffic between the two communicating parties that could be
interpreted by an involved proxy (configured or transparent) as
genuine, real, HTTP traffic with content and thereby poison its
cache. That cached poisoned content could then be served to all
users of that proxy.
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2025-10148
Upstream patch:
https://github.com/curl/curl/commit/84db7a9eae8468c0445b15aa806fa
(From OE-Core rev: 3793ee12d8da4f8f90a0ffcad180ef8122251491)
Signed-off-by: Hitendra Prajapati <hprajapati@mvista.com>
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Introduce new packageconfig to explicitly avoid compilation of
experimental code. Note that the code was not compiled by default also
before this patch, this now makes it explicit and makes it possible to
check for the flags in cve-check code.
This is less intrusive change than a patch removing the code which was
rejected in patch review.
This will solve CVE-2025-59777 and CVE-2025-62689 as the vulnerable code
is not compiled by default.
Set appropriate CVE status for these CVEs based on new packageconfig.
(From OE-Core rev: 9e3c0ae261afb7b9ff9528dbc147fb6c89d5a624)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Due to what looks like a copy'n'paste mistake, the environment setup script
might override 'CURL_CA_BUNDLE' from the host env instead of leaving it
untouched. Fix that.
(cherry picked from commit 545e43a7a45be02fda8fc3af69faa20e889f58c4)
CC: changqing.li@windriver.com
CC: raj.khem@gmail.com
CC: Peter.Marko@siemens.com
(From OE-Core rev: ef198b0c6063ede32cb93fe44eb89937c076a073)
Signed-off-by: Moritz Haase <Moritz.Haase@bmw.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
When the package is installed directly on the machine (instead of
installing it in the rootfs directly), the postinstall script fails with
the following error:
/usr/sbin/update-ca-certificates: line 75: shift: shift count out of range
The reason is that the "update-ca-certificates" script is executed with
the "--sysroot" argument, and as the sysroot $D is passed. However on the
target system this variable doesn't exist, so the argument is passed without
this mandatory value, and the execution fails.
To avoid this error, check if the $D variable exists, and pass the --sysroot
argument only when it does.
Reported-by: WXbet <Wxbet@proton.me>
(From OE-Core rev: 9a2bd3b6e2e53071a1463d2804d0d4fb17b1814f)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit cf39461e97098a1b28693299677888ba7e8bfccf)
Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
0001-Revert-mozilla-certdata2pem.py-print-a-warning-for-e.patch
0001-update-ca-certificates-don-t-use-Debianisms-in-run-p.patch
refreshed for 20250419
0002-sbin-update-ca-certificates-add-a-sysroot-option.patch
removed since it's included in 20250419
(From OE-Core rev: dd05818a422c8c5be1aef06405d200280b382b91)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit e39cc1fb7234bf2b37856296d3c0d10ddf8cae64)
Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
ca-certificates/0002-update-ca-certificates-use-SYSROOT.patch
was using a non-standard environment variable, and was replaced
with a patch that adds a command line option (and then this
was submitted upstream). ca-certificates recipe was tweaked accordingly,
and nothing else in core or meta-oe is using update-ca-certificates.
Drop default-sysroot.patch as the use case is unclear: sysroot
is explicitly specified in all known invocations of update-ca-certificate,
and if there's a place where it isn't, then update-ca-certificates
will error out trying to write to /etc, and should be fixed to
explicitly specify the sysroot.
(From OE-Core rev: a80185fd72a2be183783b0e464c07f1043d7dd37)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 90d9f0ba674d4fe8e9291f0513c13dff3775c545)
Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
git repo no longer has tags for recent versions which means
we had missed several of them, and wouldn't be able to get
notifications about any future releases.
(From OE-Core rev: 44c113497c7e3f9f06604e892df1eb717bb3410d)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 81f013fd1312551628701bf36ac62746a2606dbd)
Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Provide references for how the SRCREV was arrived at for the 20240203
release.
(From OE-Core rev: b1d86653f1485aa56fe8bf050931d5b8657ee499)
Signed-off-by: Theodore A. Roth <troth@openavr.org>
Signed-off-by: Theodore A. Roth <theodore_roth@trimble.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 6916cdb0f05f6644edb1e432a9421595abb9f0ca)
Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The 20240203 version is the same as used in Ubuntu >= 24.04 and Debian
Trixie (testing).
(From OE-Core rev: 63620f034019b3b3585e263bd26b3fadd9a1692e)
Signed-off-by: Theodore A. Roth <troth@openavr.org>
Signed-off-by: Theodore A. Roth <theodore_roth@trimble.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit ce19168885a04b0d77e81c1fd1c4262b195a47d4)
Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Prevent attackers to cause a denial of service (application crash) or
possibly have unspecified other impact when the application processes
untrusted LZ4 frames. For example, LZ4F_createCDict_advanced in
lib/lz4frame.c mishandles NULL checks.
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2025-62813
Upstream patch:
f64efec011
(From OE-Core rev: 0a63e3e120cc6958e2963a3ad510ec7c03f1adae)
Signed-off-by: David Nyström <david.nystrom@est.tech>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
In native/nativesdk builds, sysconfdir refers to a recipe sysroot
directory, which will disappear once the workdir is cleaned up, breaking
libcurl's HTTPS connections.
By simply not setting --with-ca-bundle at all in non-target builds, curl
defaults to the host system's CA certificates, which is desirable anyways
to allow builds in environments that require local CA certificates.
(From OE-Core rev: 4909a46e93ba774c960c3d3c277e2a669af3fea6)
(From OE-Core rev: 0f98fecda8a0436f760e6fd9f3b7eb510e5258b8)
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
There is a bug libicu that causes libicu to be installed incorrectly when
the build system uses long paths (more than 512 chars).
This condition is not very difficult to trigger on a OE build system
due to the long paths an the deep of the directories that are usually
generated by default.
Also the bug is very subtle and won't be detected by the QA post-install
processes because what this bug causes is that a different version of
libicudata.so.X.Y (one without data) is installed instead of the one
containing the data, but there won't be any file missed on the installation
(just that it installed the wrong one).
See: https://unicode-org.atlassian.net/browse/ICU-22813
This patch backports the fix from upstream/main
(From OE-Core rev: 67d1352873957decacde30ff208fb7bb635b0c5d)
(From OE-Core rev: 0860992436092f7651e22e2b894f0d0a365a9bb0)
Signed-off-by: Carlos Alberto Lopez Perez <clopez@igalia.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Benjamin Hahn <B.Hahn@phytec.de>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Disable NLS in the build when USE_NLS is off.
(From OE-Core rev: b94798ecd535956ef4565663710ea9a701ff21ed)
This change corresponds to upstream eeb3974472
from master .
Since the p11-kit version are different between master & scarthgap
applied the patch manually
(From OE-Core rev: 96602ea67463170c4cadf748525f5615ce9bbd91)
Signed-off-by: Philip Lorenz <philip.lorenz@bmw.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: AshishKumar Mishra <emailaddress.ashish@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
1, A cookie is set using the secure keyword for https://target
2, curl is redirected to or otherwise made to speak with http://target
(same hostname, but using clear text HTTP) using the same cookie set
3, The same cookie name is set - but with just a slash as path (path="/").
Since this site is not secure, the cookie should just be ignored.
4, A bug in the path comparison logic makes curl read outside a heap buffer boundary
The bug either causes a crash or it potentially makes the comparison come to
the wrong conclusion and lets the clear-text site override the contents of
the secure cookie, contrary to expectations and depending on the memory contents
immediately following the single-byte allocation that holds the path.
The presumed and correct behavior would be to plainly ignore the second set of
the cookie since it was already set as secure on a secure host so overriding
it on an insecure host should not be okay.
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2025-9086
Upstream patch:
https://github.com/curl/curl/commit/c6ae07c6a541e0e96d0040afb6
(From OE-Core rev: b0cc7001a628deaa96d1aebb5ded52797898a0be)
Signed-off-by: Yogita Urade <yogita.urade@windriver.com>
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>
Backport a fix for native build with gcc-15 on host
(From OE-Core rev: cef0a6c3245a2556614f7e009c2e00e1eb16e08e)
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
GCC15 is switching defaults to C23 and gdbm is not yet ready to
compile using C23 std.
For scarthgap also add it in BUILD_CFLAGS.
(From OE-Core rev: 97989d81c5e30434594beadd9449e907e98d3ceb)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The fix to make this work with GCC15/C23 caused problems with older gcc versions.
Add a fix for that.
(From OE-Core rev: 237085506a454fb927389d681f30c8c995bc7b2b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Handles CVE-2025-53905, CVE-2025-53906, CVE-2025-55157, CVE-2025-55158.
Changes between 9.1.1198 -> 9.1.1652
====================================
https://github.com/vim/vim/compare/v9.1.1198...v9.1.1652
Refresh patches.
Disable newly introduced wayland support (in patch version 1485).
To this belongs also adding recursion in delete command for dir auto
which was newly failing as there is wayland directory inside now.
If someone is interested, this can be probably enabled, but without
additional work it results in compilation error due to function
redefinition conflicts.
(From OE-Core rev: e87d427d928234ef0441f9ce1fe8631fbe471094)
(From OE-Core rev: 052fd7e55d2c73f13f63267fbfb5e39fa504baa3)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Pick relevant commit from 3.8.10 release MR [1].
The MR contains referece to undiscoled issue, so any security relevant
patch should be picked.
Binary test file was added as separate file as binary diffs are not
supported.
[1] https://gitlab.com/gnutls/gnutls/-/merge_requests/1979
(From OE-Core rev: d1aaef9bbaa240c83cc7d485b55570449203da0b)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Pick relevant commit from 3.8.10 release MR [1].
The ME contains referece to undiscoled issue, so any security relevant
patch should be picked.
Binary test file was added as separate file as binary diffs are not
supported.
[1] https://gitlab.com/gnutls/gnutls/-/merge_requests/1979
(From OE-Core rev: 8f825e7f4ca36d7ac62062e452cea256f3c058aa)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
There exists a vulnerability in SQLite versions before 3.50.2 where the
number of aggregate terms could exceed the number of columns available.
This could lead to a memory corruption issue.
(From OE-Core rev: 52499a5ea3b4ba145914aca873844ab718953289)
Signed-off-by: Roland Kovacs <roland.kovacs@est.tech>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
