Backport commit mentioned in NVD DB links.
94e1c00176
(From OE-Core rev: 410cdbc70cfba709ec5bef508e772f52514ba28a)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Backport from 50a51cb7e6
CVE-2022-1586: pcre2: Out-of-bounds read in compile_xclass_matchingpath in pcre2_jit_compile.c.
(From OE-Core rev: fb6c980105ffd0262517299ab366218c61cc0665)
Signed-off-by: Hitendra Prajapati <hprajapati@mvista.com>
Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
(cherry picked from commit 7519eb1cb624bb576cfe60f7470d40c566818ac3)
Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace pcre-cross.patch with the (default) option
to use pre-built tables; the README says it's ok, and
recommended in cross-compile situations. The option
was in the recipe from the start and neither the commit
that adds the recipe, nor the patch to make it work explain
why.
License-Update: copyright years
(From OE-Core rev: df85581e8ac01183b13dd7c3e926ee93f50214f2)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
(From OE-Core rev: eb7632f593b81066da4de44bc001974d6726a118)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
LICENSE files changed:
Amend licence to relax its conditions for chains of binary distributions.
removed included patches
includes CVE-2017-8399
(From OE-Core rev: d8ea0674d1feee803b75cf837e8d029619f8d663)
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A fuzz on libpcre1 through the pcretest utility revealed an invalid read in the
library. For who is interested in a detailed description of the bug, will
follow a feedback from upstream:
This was a genuine bug in the 32-bit library. Thanks for finding it. The crash
was caused by trying to find a Unicode property for a code value greater than
0x10ffff, the Unicode maximum, when running in non-UTF mode (where character
values can be up to 0xffffffff).
(From OE-Core rev: 1b87201784e733f3a9d436f56cb5a6151ba6bdfa)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The pcre2test.c in PCRE2 10.23 allows remote attackers to cause a denial of
service (heap-based buffer overflow) or possibly have unspecified other impact
via a crafted regular expression.
(From OE-Core rev: dd63a26fedb8a578d34850ede4c27e26b8876e7e)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are two major versions of the PCRE library. The newest version, PCRE2,
was released in 2015 and is at version 10.22.
The original, very widely deployed PCRE library, originally released in 1997,
is at version 8.40, and the API and feature set are stable, future releases
will be for bugfixes only. All new future features will be to PCRE2, not the
original PCRE 8.x series.
The newer vte depends on libpcre2, so add it.
(From OE-Core rev: f7165d379cb67c4d4918a8a3e9509d3d823d61da)
(From OE-Core rev: 69c4d94dd6b825c710c6e76fe77e5255ddd1183d)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
