Re: [OE-core] [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage
Warning: wall of text ahead. Sorry about that, but I believe it is important that we get this right if we are redesigning it. TL;DR: see the end for the new suggested licensing variables. > -Original Message- > From: openembedded-de...@lists.openembedded.org de...@lists.openembedded.org> On Behalf Of Richard Purdie > Sent: den 18 februari 2022 15:14 > To: Saul Wold ; openembedded- > architect...@lists.openembedded.org; OE-core c...@lists.openembedded.org>; OpenEmbedded Devel List de...@lists.openembedded.org> > Subject: Re: [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage > > On Thu, 2022-02-17 at 15:01 -0800, Saul Wold wrote: > > I am working on a proposal to re-write how INCOMPATIBLE_LICENSES is used > > and processed to possibly include a COMPATIBLE_LICENSES variable as > > well, see PeterK's email [0] > > > > I am trying to determine the usage of WHITELIST_ which would be > > used to override a license that might be listed in INCOMPATIBLE_LICENSES > > variable. > > > > Randy and I have done a quick and dirty survey of a 100 or so layers > > (thanks Randy) and could not find any real usage other than what's > > currently in OE-Core for WHITELIST_GPL-3.0. > > > > If you are using WHITELIST_, please let me reply with your > > usage. > > > > > > [0] https://lists.openembedded.org/g/openembedded-devel/message/95166 > > We need to be mindful that we need to resolve this to unblock the other > language changes and feature creep here is potentially problematic. I do > think it is worth trying to improve things rather than blindly allowing > the horrible syntax in this variable to continue though. > > The test case we have for this currently is: > > WHITELIST_GPL-3.0:pn-core-image-minimal = "bash" > > so I'd wondered about an alternative of: > > INCOMPATIBLE_LICENSE_EXCEPTIONS:pn-core-image-minimal = "bash:GPL-3.0" You do not really need the license here (more than possibly as information to anyone reading the code). Specifying that a package is allowed in an image regardless of its licenses can just as well be done by allowing the variable to take a list of packages: INCOMPATIBLE_LICENSE_EXCEPTIONS:pn-core-image-minimal = "bash readline" An alternative (and in my opinion better) variable name would be: IMAGE_ALLOW_PACKAGES:pn-core-image-minimal = "bash readline" focusing on that this is a list of _packages_ allowed for a given _image_. This does not explicitly mention licenses, but I do not believe that is needed. After all there could be multiple reasons a package is not allowed in an image and this variable would allow to ignore them all because that is typically what you want to do: specify that you really want that package in that image. I guess this is in some sense the opposite of PACKAGE_EXCLUDE. And I guess like :append vs :remove, if someone for some reason specifies a package in both IMAGE_ALLOW_PACKAGES and PACKAGE_EXCLUDE, then the later should win (to err on the side of caution). For the case where you want to allow a recipe to be built despite it using licenses that are otherwise not allowed you can simply use INCOMPATIBLE_LICENSE:pn-foo = "" and don't really need a separate variable for it. > which matches the current functionality, removes the issue that the name > of the variable is unknown without iterating every possible license name > and makes it clear where it is applying to. > > I don't really like INCOMPATIBLE_LICENSE_ALLOWED_RECIPES since: > > a) it is long > b) it refers to recipes when it works against packages > > (INCOMPATIBLE_LICENSE_PACKAGE_EXCEPTIONS is more correct but still long) > > I do like it mentioning INCOMPATIBLE_LICENSE in full since it works in > conjunction with that variable and that is definitely not clear from the > current WHITELIST_XXX until you look at the code. > > I'm still of the opinion the AVAILABLE_LICENSES variable is something we > should be aiming to remove ultimately too, it has horrible issues with > layers changing hashes for all recipes. Since I was the one to introduce it, I will answer to that. It was introduced so that it is possible to specify compatible licenses instead of incompatible licenses by basically calculating the incompatible licenses by taking the set of available licenses minus the set of compatible licenses. If a mechanism to do that is introduced, e.g., by adding support for a COMPATIBLE_LICENSES in addition to INCOMPATIBLE_LICENSE, then I am of the opinion that we can remove AVAILABLE_LICENSES again. We also need this mechanism in the code for handling allowed vs disallowed licenses because the current code really cannot handled a list of many hundreds of incompatible licenses, which is what we got after all SPDX licenses were added to OE-Core. The code is extremely inefficient and evaluates the list of incompatible licenses over and over again. In our case that meant the recipe parsing time tripled. > Cheers, > > Richard That said, we really need two sets of
Re: [OE-core] [dunfell][PATCH v2] openssl: upgrade to 1.1.1m for CVE-2021-4160
On Fri, Feb 18, 2022 at 3:36 PM Steve Sakoman wrote:
> On Tue, Feb 15, 2022 at 5:59 PM Tim Orling wrote:
> >
> > Changes are only security and bug fixes.
>
> I'm seeing ptest errors:
>
> WARNING: core-image-sato-sdk-ptest-1.0-r0 do_testimage: There were
> failing ptests.
> Traceback (most recent call last):
> File
> "/home/pokybuild/yocto-worker/qemux86-64-ptest/build/meta/lib/oeqa/core/decorator/__init__.py",
> line 36, in wrapped_f
> return func(*args, **kwargs)
> File
> "/home/pokybuild/yocto-worker/qemux86-64-ptest/build/meta/lib/oeqa/core/decorator/__init__.py",
> line 36, in wrapped_f
> return func(*args, **kwargs)
> File
> "/home/pokybuild/yocto-worker/qemux86-64-ptest/build/meta/lib/oeqa/core/decorator/__init__.py",
> line 36, in wrapped_f
> return func(*args, **kwargs)
> File
> "/home/pokybuild/yocto-worker/qemux86-64-ptest/build/meta/lib/oeqa/runtime/cases/ptest.py",
> line 25, in test_ptestrunner_expectfail
> self.do_ptestrunner()
> File
> "/home/pokybuild/yocto-worker/qemux86-64-ptest/build/meta/lib/oeqa/runtime/cases/ptest.py",
> line 108, in do_ptestrunner
> self.fail(failmsg)
> AssertionError: Failed ptests:
> {'openssl': ['test/recipes/30-test_evp_extra.t,_test_returned_1']}
>
I saw this on qemux86-64, but was not sure it was due to the upgrade or a
one off infra issue. I’ll dig deeper and see what might be happening.
> Happens with both qemuarm64-ptest and qemux86-64-ptest:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/2863
> https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/3124
>
> Steve
>
> > https://www.openssl.org/news/cl111.txt
> > https://git.openssl.org/?p=openssl.git;a=log;h=refs/tags/OpenSSL_1_1_1m
> >
> > CVE: CVE-2021-4160
> >
> > https://nvd.nist.gov/vuln/detail/CVE-2021-4160
> >
> > Signed-off-by: Tim Orling
> > ---
> > Changes in v2:
> > - drop SRC_URI[md5sum] that devtool snuck in.
> >
> > .../openssl/{openssl_1.1.1l.bb => openssl_1.1.1m.bb}| 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > rename meta/recipes-connectivity/openssl/{openssl_1.1.1l.bb =>
> openssl_1.1.1m.bb} (98%)
> >
> > diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1l.bb
> b/meta/recipes-connectivity/openssl/openssl_1.1.1m.bb
> > similarity index 98%
> > rename from meta/recipes-connectivity/openssl/openssl_1.1.1l.bb
> > rename to meta/recipes-connectivity/openssl/openssl_1.1.1m.bb
> > index bf7cd6527ef..c6f8499d4f5 100644
> > --- a/meta/recipes-connectivity/openssl/openssl_1.1.1l.bb
> > +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1m.bb
> > @@ -24,7 +24,7 @@ SRC_URI_append_class-nativesdk = " \
> > file://environment.d-openssl.sh \
> > "
> >
> > -SRC_URI[sha256sum] =
> "0b7a3e5e59c34827fe0c3a74b7ec8baef302b98fa80088d7f9153aa16fa76bd1"
> > +SRC_URI[sha256sum] =
> "f89199be8b23ca45fc7cb9f1d8d3ee67312318286ad030f5316aca6462db6c96"
> >
> > inherit lib_package multilib_header multilib_script ptest
> > MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
> > --
> > 2.30.2
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161955):
https://lists.openembedded.org/g/openembedded-core/message/161955
Mute This Topic: https://lists.openembedded.org/mt/89179173/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Proposal: INCOMPATIBLE_LICENSE_EXCEPTION
Folks, As a follow-on to yesterday's email and replies, I would like to make the following proposal for dealing with the changes to INCOMPATIBLE_LICENSE and associated variables. Current Usage: INCOMPATIBLE_LICENSE is a list of licenses that are considered incompatible with a distro's requirements. This is used to compare against packages built by a given recipe. A set of exception variables based on the license name (currently WHITELIST_) that contains a list of recipes that will be checked against the current recipe (PN) being evaluated. If it's in that list then all packages in that recipe will be built and included and the rest of the evaluation will be skipped. Otherwise, the packages (PKGS) from the recipe will be evaluated to see if any have a package specific license (LICENSE:). If a package has a license other than the INCOMPATIBLE_LICENSE the recipe will be built and any packages with the INCOMPATIBLE_LICENSE will be excluded from being packaged in package.bbclass via LICENSE_EXCLUSION- internal variable. The exception is predominately used for GPLv3 related packages, based on the emails replies overnight. Proposal: Keep the existing INCOMPATIBLE_LICENSE variable with the same behavior. The values in INCOMPATIBLE_LICENSE should be SDPX normalized license strings. As Richard has already suggested an alternative variable that is more meaningful: INCOMPATIBLE_LICENSE_EXCEPTION with an a : value. Rename the LICENSE_EXCLUSION- variable to make it clear that it is an internal variable. The usage of the _EXCEPTION variable should contain pkg names not recipe name. ** This would be an important change ** Clean up code as appropriate to ensure the exceptions are handled once and identified during parsing. I will start working on the implementation, Monday is a holiday in the US, so this should give sometime for this to be reviewed for Tuesday. -- Sau! -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161951): https://lists.openembedded.org/g/openembedded-core/message/161951 Mute This Topic: https://lists.openembedded.org/mt/89240704/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] libgit2: Upgrade to 1.4.1
this is bugfix release
https://github.com/libgit2/libgit2/releases/tag/v1.4.1
Signed-off-by: Khem Raj
---
.../libgit2/{libgit2_1.4.0.bb => libgit2_1.4.1.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-support/libgit2/{libgit2_1.4.0.bb => libgit2_1.4.1.bb}
(78%)
diff --git a/meta/recipes-support/libgit2/libgit2_1.4.0.bb
b/meta/recipes-support/libgit2/libgit2_1.4.1.bb
similarity index 78%
rename from meta/recipes-support/libgit2/libgit2_1.4.0.bb
rename to meta/recipes-support/libgit2/libgit2_1.4.1.bb
index 23a195b43b3..da33893b97d 100644
--- a/meta/recipes-support/libgit2/libgit2_1.4.0.bb
+++ b/meta/recipes-support/libgit2/libgit2_1.4.1.bb
@@ -5,8 +5,8 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=e5a9227de4cb6afb5d35ed7b0fdf480d"
DEPENDS = "curl openssl zlib libssh2 libgcrypt libpcre2"
-SRC_URI = "git://github.com/libgit2/libgit2.git;branch=main;protocol=https"
-SRCREV = "1d5b9bd86dccc7347aaadf5e3ab122eed9413404"
+SRC_URI =
"git://github.com/libgit2/libgit2.git;branch=maint/v1.4;protocol=https"
+SRCREV = "fdd15bcfca6b2ec4b7ecad1aa11a396cb15bd064"
S = "${WORKDIR}/git"
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161952):
https://lists.openembedded.org/g/openembedded-core/message/161952
Mute This Topic: https://lists.openembedded.org/mt/89243019/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [dunfell][PATCH v2] openssl: upgrade to 1.1.1m for CVE-2021-4160
On Tue, Feb 15, 2022 at 5:59 PM Tim Orling wrote:
>
> Changes are only security and bug fixes.
I'm seeing ptest errors:
WARNING: core-image-sato-sdk-ptest-1.0-r0 do_testimage: There were
failing ptests.
Traceback (most recent call last):
File
"/home/pokybuild/yocto-worker/qemux86-64-ptest/build/meta/lib/oeqa/core/decorator/__init__.py",
line 36, in wrapped_f
return func(*args, **kwargs)
File
"/home/pokybuild/yocto-worker/qemux86-64-ptest/build/meta/lib/oeqa/core/decorator/__init__.py",
line 36, in wrapped_f
return func(*args, **kwargs)
File
"/home/pokybuild/yocto-worker/qemux86-64-ptest/build/meta/lib/oeqa/core/decorator/__init__.py",
line 36, in wrapped_f
return func(*args, **kwargs)
File
"/home/pokybuild/yocto-worker/qemux86-64-ptest/build/meta/lib/oeqa/runtime/cases/ptest.py",
line 25, in test_ptestrunner_expectfail
self.do_ptestrunner()
File
"/home/pokybuild/yocto-worker/qemux86-64-ptest/build/meta/lib/oeqa/runtime/cases/ptest.py",
line 108, in do_ptestrunner
self.fail(failmsg)
AssertionError: Failed ptests:
{'openssl': ['test/recipes/30-test_evp_extra.t,_test_returned_1']}
Happens with both qemuarm64-ptest and qemux86-64-ptest:
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/2863
https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/3124
Steve
> https://www.openssl.org/news/cl111.txt
> https://git.openssl.org/?p=openssl.git;a=log;h=refs/tags/OpenSSL_1_1_1m
>
> CVE: CVE-2021-4160
>
> https://nvd.nist.gov/vuln/detail/CVE-2021-4160
>
> Signed-off-by: Tim Orling
> ---
> Changes in v2:
> - drop SRC_URI[md5sum] that devtool snuck in.
>
> .../openssl/{openssl_1.1.1l.bb => openssl_1.1.1m.bb}| 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> rename meta/recipes-connectivity/openssl/{openssl_1.1.1l.bb =>
> openssl_1.1.1m.bb} (98%)
>
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1l.bb
> b/meta/recipes-connectivity/openssl/openssl_1.1.1m.bb
> similarity index 98%
> rename from meta/recipes-connectivity/openssl/openssl_1.1.1l.bb
> rename to meta/recipes-connectivity/openssl/openssl_1.1.1m.bb
> index bf7cd6527ef..c6f8499d4f5 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1l.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1m.bb
> @@ -24,7 +24,7 @@ SRC_URI_append_class-nativesdk = " \
> file://environment.d-openssl.sh \
> "
>
> -SRC_URI[sha256sum] =
> "0b7a3e5e59c34827fe0c3a74b7ec8baef302b98fa80088d7f9153aa16fa76bd1"
> +SRC_URI[sha256sum] =
> "f89199be8b23ca45fc7cb9f1d8d3ee67312318286ad030f5316aca6462db6c96"
>
> inherit lib_package multilib_header multilib_script ptest
> MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
> --
> 2.30.2
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161954):
https://lists.openembedded.org/g/openembedded-core/message/161954
Mute This Topic: https://lists.openembedded.org/mt/89179173/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage
On Fri, 2022-02-18 at 23:34 +, Peter Kjellerstedt wrote: > Warning: wall of text ahead. Sorry about that, but I believe it is > important that we get this right if we are redesigning it. > > TL;DR: see the end for the new suggested licensing variables. > > > -Original Message- > > From: openembedded-de...@lists.openembedded.org > de...@lists.openembedded.org> On Behalf Of Richard Purdie > > Sent: den 18 februari 2022 15:14 > > To: Saul Wold ; openembedded- > > architect...@lists.openembedded.org; OE-core > c...@lists.openembedded.org>; OpenEmbedded Devel List > de...@lists.openembedded.org> > > Subject: Re: [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage > > > > On Thu, 2022-02-17 at 15:01 -0800, Saul Wold wrote: > > > I am working on a proposal to re-write how INCOMPATIBLE_LICENSES is used > > > and processed to possibly include a COMPATIBLE_LICENSES variable as > > > well, see PeterK's email [0] > > > > > > I am trying to determine the usage of WHITELIST_ which would be > > > used to override a license that might be listed in INCOMPATIBLE_LICENSES > > > variable. > > > > > > Randy and I have done a quick and dirty survey of a 100 or so layers > > > (thanks Randy) and could not find any real usage other than what's > > > currently in OE-Core for WHITELIST_GPL-3.0. > > > > > > If you are using WHITELIST_, please let me reply with your > > > usage. > > > > > > > > > [0] https://lists.openembedded.org/g/openembedded-devel/message/95166 > > > > We need to be mindful that we need to resolve this to unblock the other > > language changes and feature creep here is potentially problematic. I do > > think it is worth trying to improve things rather than blindly allowing > > the horrible syntax in this variable to continue though. > > > > The test case we have for this currently is: > > > > WHITELIST_GPL-3.0:pn-core-image-minimal = "bash" > > > > so I'd wondered about an alternative of: > > > > INCOMPATIBLE_LICENSE_EXCEPTIONS:pn-core-image-minimal = "bash:GPL-3.0" > > You do not really need the license here (more than possibly as > information to anyone reading the code). Specifying that a package is > allowed in an image regardless of its licenses can just as well be > done by allowing the variable to take a list of packages: > > INCOMPATIBLE_LICENSE_EXCEPTIONS:pn-core-image-minimal = "bash readline" I'm not sure I agree with that. I get the feeling some people want to allow these packages as long as they're with license X. Licenses can change over time and this allows a safety net that if it changes, the exception has to be updated too. > An alternative (and in my opinion better) variable name would be: > > IMAGE_ALLOW_PACKAGES:pn-core-image-minimal = "bash readline" > > focusing on that this is a list of _packages_ allowed for a given > _image_. This does not explicitly mention licenses, but I do not > believe that is needed. If you assume this isn't being done on license reasons, sure. Except see above, I think this does need to account for licenses, at least the way many use it. > After all there could be multiple reasons a package is not allowed in > an image and this variable would allow to > ignore them all because that is typically what you want to do: > specify that you really want that package in that image. I guess > this is in some sense the opposite of PACKAGE_EXCLUDE. And I guess > like :append vs :remove, if someone for some reason specifies a > package in both IMAGE_ALLOW_PACKAGES and PACKAGE_EXCLUDE, then the > later should win (to err on the side of caution). How would IMAGE_ALLOW_PACKAGES work and be different to IMAGE_INSTALL? This interface would likely confuse more users than it would help. > For the case where you want to allow a recipe to be built despite > it using licenses that are otherwise not allowed you can simply use > > INCOMPATIBLE_LICENSE:pn-foo = "" > > and don't really need a separate variable for it. That is a good point and perhaps should influence how an INCOMPATIBLE_LICENSE_EXCEPTIONS should be package based rather than recipe. I doubt the pn- override existed when that variable was originally added. > > I'm still of the opinion the AVAILABLE_LICENSES variable is something we > > should be aiming to remove ultimately too, it has horrible issues with > > layers changing hashes for all recipes. > > Since I was the one to introduce it, I will answer to that. It was > introduced so that it is possible to specify compatible licenses > instead of incompatible licenses by basically calculating the > incompatible licenses by taking the set of available licenses minus > the set of compatible licenses. If a mechanism to do that is > introduced, e.g., by adding support for a COMPATIBLE_LICENSES in > addition to INCOMPATIBLE_LICENSE, then I am of the opinion that we > can remove AVAILABLE_LICENSES again. > > We also need this mechanism in the code for handling allowed vs > disallowed licenses because the current code
Re: [OE-core] [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage
> -Original Message- > From: Richard Purdie > Sent: den 19 februari 2022 01:45 > To: Peter Kjellerstedt ; Saul Wold > ; openembedded- > architect...@lists.openembedded.org; OE-core c...@lists.openembedded.org>; OpenEmbedded Devel List de...@lists.openembedded.org> > Subject: Re: [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage > > On Fri, 2022-02-18 at 23:34 +, Peter Kjellerstedt wrote: > > Warning: wall of text ahead. Sorry about that, but I believe it is > > important that we get this right if we are redesigning it. > > > > TL;DR: see the end for the new suggested licensing variables. > > > > > -Original Message- > > > From: openembedded-de...@lists.openembedded.org > > de...@lists.openembedded.org> On Behalf Of Richard Purdie > > > Sent: den 18 februari 2022 15:14 > > > To: Saul Wold ; openembedded- > > > architect...@lists.openembedded.org; OE-core > > c...@lists.openembedded.org>; OpenEmbedded Devel List > > de...@lists.openembedded.org> > > > Subject: Re: [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage > > > > > > On Thu, 2022-02-17 at 15:01 -0800, Saul Wold wrote: > > > > I am working on a proposal to re-write how INCOMPATIBLE_LICENSES is > > > > used and processed to possibly include a COMPATIBLE_LICENSES variable > > > > as well, see PeterK's email [0] > > > > > > > > I am trying to determine the usage of WHITELIST_ which > > > > would be used to override a license that might be listed in > > > > INCOMPATIBLE_LICENSES variable. > > > > > > > > Randy and I have done a quick and dirty survey of a 100 or so layers > > > > (thanks Randy) and could not find any real usage other than what's > > > > currently in OE-Core for WHITELIST_GPL-3.0. > > > > > > > > If you are using WHITELIST_, please let me reply with your > > > > usage. > > > > > > > > [0] https://lists.openembedded.org/g/openembedded-devel/message/95166 > > > > > > We need to be mindful that we need to resolve this to unblock the > > > other language changes and feature creep here is potentially > > > problematic. I do think it is worth trying to improve things rather > > > than blindly allowing the horrible syntax in this variable to > > > continue though. > > > > > > The test case we have for this currently is: > > > > > > WHITELIST_GPL-3.0:pn-core-image-minimal = "bash" > > > > > > so I'd wondered about an alternative of: > > > > > > INCOMPATIBLE_LICENSE_EXCEPTIONS:pn-core-image-minimal = "bash:GPL-3.0" > > > > You do not really need the license here (more than possibly as > > information to anyone reading the code). Specifying that a package is > > allowed in an image regardless of its licenses can just as well be > > done by allowing the variable to take a list of packages: > > > > INCOMPATIBLE_LICENSE_EXCEPTIONS:pn-core-image-minimal = "bash readline" > > I'm not sure I agree with that. I get the feeling some people want to > allow these packages as long as they're with license X. Licenses can > change over time and this allows a safety net that if it changes, the > exception has to be updated too. Well, to complicate matters then, if you really want to be explicit with the license exceptions you make for a recipe or a package, I will argue that you need to do it for all incompatible licenses a recipe uses. With today's code, as soon as you allow one incompatible license for a recipe, the recipe is allowed to be built, even if it has specified multiple incompatible licenses. E.g., if we take the gnupg recipe, which specifies LICENSE = "GPLv3 & LGPLv3", and we have an INCOMPATIBLE_LICENSE = "GPL-3.0-only LGPL-3.0-only", with your example I would then expect the following: INCOMPATIBLE_LICENSE_EXCEPTIONS:pn-core-image-minimal = "gnupg:GPL-3.0-only gnupg:LGPL-3.0-only" to allow the gnupg package to be installed in the image. However, I guess you could combine our suggestions by making the license part of the value optional, i.e., the following would then also allow the package to be included under the same conditions: INCOMPATIBLE_LICENSE_EXCEPTIONS:pn-core-image-minimal = "gnupg" > > An alternative (and in my opinion better) variable name would be: > > > > IMAGE_ALLOW_PACKAGES:pn-core-image-minimal = "bash readline" > > > > focusing on that this is a list of _packages_ allowed for a given > > _image_. This does not explicitly mention licenses, but I do not > > believe that is needed. > > If you assume this isn't being done on license reasons, sure. Except > see above, I think this does need to account for licenses, at least > the way many use it. > > > After all there could be multiple reasons a package is not allowed in > > an image and this variable would allow to > > ignore them all because that is typically what you want to do: > > specify that you really want that package in that image. I guess > > this is in some sense the opposite of PACKAGE_EXCLUDE. And I guess > > like :append vs :remove, if someone for some reason specifies a > > package in both IMAGE_ALLOW_PACKAGES and
Re: [OE-core] [dunfell][PATCH v2] openssl: upgrade to 1.1.1m for CVE-2021-4160
On Fri, Feb 18, 2022 at 2:27 PM Tim Orling wrote:
>
>
>
> On Fri, Feb 18, 2022 at 3:36 PM Steve Sakoman wrote:
>>
>> On Tue, Feb 15, 2022 at 5:59 PM Tim Orling wrote:
>> >
>> > Changes are only security and bug fixes.
>>
>> I'm seeing ptest errors:
>>
>> WARNING: core-image-sato-sdk-ptest-1.0-r0 do_testimage: There were
>> failing ptests.
>> Traceback (most recent call last):
>> File
>> "/home/pokybuild/yocto-worker/qemux86-64-ptest/build/meta/lib/oeqa/core/decorator/__init__.py",
>> line 36, in wrapped_f
>> return func(*args, **kwargs)
>> File
>> "/home/pokybuild/yocto-worker/qemux86-64-ptest/build/meta/lib/oeqa/core/decorator/__init__.py",
>> line 36, in wrapped_f
>> return func(*args, **kwargs)
>> File
>> "/home/pokybuild/yocto-worker/qemux86-64-ptest/build/meta/lib/oeqa/core/decorator/__init__.py",
>> line 36, in wrapped_f
>> return func(*args, **kwargs)
>> File
>> "/home/pokybuild/yocto-worker/qemux86-64-ptest/build/meta/lib/oeqa/runtime/cases/ptest.py",
>> line 25, in test_ptestrunner_expectfail
>> self.do_ptestrunner()
>> File
>> "/home/pokybuild/yocto-worker/qemux86-64-ptest/build/meta/lib/oeqa/runtime/cases/ptest.py",
>> line 108, in do_ptestrunner
>> self.fail(failmsg)
>> AssertionError: Failed ptests:
>> {'openssl': ['test/recipes/30-test_evp_extra.t,_test_returned_1']}
>
>
> I saw this on qemux86-64, but was not sure it was due to the upgrade or a one
> off infra issue. I’ll dig deeper and see what might be happening.
I re-ran the test and got the same error, so it doesn't seem to be intermittent.
Thanks!
Steve
>
>>
>> Happens with both qemuarm64-ptest and qemux86-64-ptest:
>>
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/2863
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/3124
>>
>> Steve
>>
>> > https://www.openssl.org/news/cl111.txt
>> > https://git.openssl.org/?p=openssl.git;a=log;h=refs/tags/OpenSSL_1_1_1m
>> >
>> > CVE: CVE-2021-4160
>> >
>> > https://nvd.nist.gov/vuln/detail/CVE-2021-4160
>> >
>> > Signed-off-by: Tim Orling
>> > ---
>> > Changes in v2:
>> > - drop SRC_URI[md5sum] that devtool snuck in.
>> >
>> > .../openssl/{openssl_1.1.1l.bb => openssl_1.1.1m.bb}| 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > rename meta/recipes-connectivity/openssl/{openssl_1.1.1l.bb =>
>> > openssl_1.1.1m.bb} (98%)
>> >
>> > diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1l.bb
>> > b/meta/recipes-connectivity/openssl/openssl_1.1.1m.bb
>> > similarity index 98%
>> > rename from meta/recipes-connectivity/openssl/openssl_1.1.1l.bb
>> > rename to meta/recipes-connectivity/openssl/openssl_1.1.1m.bb
>> > index bf7cd6527ef..c6f8499d4f5 100644
>> > --- a/meta/recipes-connectivity/openssl/openssl_1.1.1l.bb
>> > +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1m.bb
>> > @@ -24,7 +24,7 @@ SRC_URI_append_class-nativesdk = " \
>> > file://environment.d-openssl.sh \
>> > "
>> >
>> > -SRC_URI[sha256sum] =
>> > "0b7a3e5e59c34827fe0c3a74b7ec8baef302b98fa80088d7f9153aa16fa76bd1"
>> > +SRC_URI[sha256sum] =
>> > "f89199be8b23ca45fc7cb9f1d8d3ee67312318286ad030f5316aca6462db6c96"
>> >
>> > inherit lib_package multilib_header multilib_script ptest
>> > MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
>> > --
>> > 2.30.2
>> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161958):
https://lists.openembedded.org/g/openembedded-core/message/161958
Mute This Topic: https://lists.openembedded.org/mt/89179173/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] rust: Introduce RS_BUILD_ARCH to handle ppc64le
On Fri, 18 Feb 2022, at 16:43, Khem Raj wrote: > On Thu, Feb 17, 2022 at 9:43 PM Andrew Jeffery wrote: >> >> On modern Power systems `uname -m` reports 'ppc64le'. However, Rust's >> toolchain names the architecture 'powerpc64le'. >> >> Introduce RS_BUILD_ARCH to provide an indirection to fix this mismatch. >> >> I've tested each of the generated URIs for Power using the output from >> `bitbake -e rust-native` and could successfully fetch the artifacts. >> > thanks > can you also check if arch_to_rust_target_arch() in > meta/recipes-devtools/rust/rust-common.inc > is computing it right for ppc64le case ? Yep, I'll poke at that. Andrew -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161957): https://lists.openembedded.org/g/openembedded-core/message/161957 Mute This Topic: https://lists.openembedded.org/mt/89227468/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [Openembedded-architecture] [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage
Hi, On Fri, Feb 18, 2022 at 09:03:53AM +0100, Alexander Kanavin wrote: > You should really try per-image INCOMPATIBLE_LICENSE :) Maintaining > those whitelists/excludes is awkward, as developers constantly want > more of them. Hmm, this rings a bell. Likely yes then :) But on the other hand this way we're quite explicit about what GPLv3 things we allow to compile. Compiling too much also hurts with compilation times too and for many use cases developers are better off working with Debian or Ubuntu tooling than compiling every bell and whistle with yocto. My list of GPLv3 recipes enabled for compilation is quite stable at: autoconf bash bc binutils bison cairo ccache coreutils diffutils elfutils findutils gawk gcc gdb gdbm gettext gnutls grep libevent libmpc libpipeline libunistring m4 make mpfr python-rfc3987 python-strict-rfc3339 readline rsync sed tcpreplay which Cheers, -Mikko -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161886): https://lists.openembedded.org/g/openembedded-core/message/161886 Mute This Topic: https://lists.openembedded.org/mt/89228507/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [Openembedded-architecture] [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage
Hi, On Thu, Feb 17, 2022 at 04:20:01PM -0800, Andre McCurdy wrote: > On Thu, Feb 17, 2022 at 3:01 PM Saul Wold wrote: > > > > Folks, > > > > I am working on a proposal to re-write how INCOMPATIBLE_LICENSES is used > > and processed to possibly include a COMPATIBLE_LICENSES variable as > > well, see PeterK's email [0] > > > > I am trying to determine the usage of WHITELIST_ which would be > > used to override a license that might be listed in INCOMPATIBLE_LICENSES > > variable. > > > > Randy and I have done a quick and dirty survey of a 100 or so layers > > (thanks Randy) and could not find any real usage other than what's > > currently in OE-Core for WHITELIST_GPL-3.0. > > > > If you are using WHITELIST_, please let me reply with your usage. > > Common case seems to be allowing gdb in debug builds of distros which > are otherwise free of GPLv3 etc, e.g. > > > https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/conf/distro/include/gdbserver-gplv3.inc > https://github.com/lgirdk/meta-mng/blob/ofw-2112.6/conf/distro/mng.conf Exactly, I'm using this in a lot of projects. Basically distro config has: INCOMPATIBLE_LICENSE_append += " GPLv3 GPLv3+ LGPLv3 LGPLv3+" and then various GPLv3 tools are allowed in build but not allowed to be part of images: WHITELIST_GPL-3.0 += "binutils" PACKAGE_EXCLUDE += "binutils-dbg binutils-staticdev binutils-dev binutils-doc binutils-locale libbfd binutils" WHITELIST_GPL-3.0 += "gdb" PACKAGE_EXCLUDE += "gdb-sdktests-dbg gdb-sdktests gdbserver gdb-dbg gdb-staticdev gdb-dev gdb-doc gdb-locale gdb" WHITELIST_GPL-3.0 += "rsync" PACKAGE_EXCLUDE += "rsync-dbg rsync-staticdev rsync-dev rsync-doc rsync-locale rsync" etc etc. Use case is that developers can install additional GPLv3 licensed tooling if they need to debug something, but product images don't include them by default. Cheers, -Mikko -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161884): https://lists.openembedded.org/g/openembedded-core/message/161884 Mute This Topic: https://lists.openembedded.org/mt/89228507/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [Openembedded-architecture] [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage
You should really try per-image INCOMPATIBLE_LICENSE :) Maintaining those whitelists/excludes is awkward, as developers constantly want more of them. Alex On Fri, 18 Feb 2022 at 09:00, Mikko Rapeli wrote: > > Hi, > > On Thu, Feb 17, 2022 at 04:20:01PM -0800, Andre McCurdy wrote: > > On Thu, Feb 17, 2022 at 3:01 PM Saul Wold wrote: > > > > > > Folks, > > > > > > I am working on a proposal to re-write how INCOMPATIBLE_LICENSES is used > > > and processed to possibly include a COMPATIBLE_LICENSES variable as > > > well, see PeterK's email [0] > > > > > > I am trying to determine the usage of WHITELIST_ which would be > > > used to override a license that might be listed in INCOMPATIBLE_LICENSES > > > variable. > > > > > > Randy and I have done a quick and dirty survey of a 100 or so layers > > > (thanks Randy) and could not find any real usage other than what's > > > currently in OE-Core for WHITELIST_GPL-3.0. > > > > > > If you are using WHITELIST_, please let me reply with your usage. > > > > Common case seems to be allowing gdb in debug builds of distros which > > are otherwise free of GPLv3 etc, e.g. > > > > > > https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/conf/distro/include/gdbserver-gplv3.inc > > https://github.com/lgirdk/meta-mng/blob/ofw-2112.6/conf/distro/mng.conf > > Exactly, I'm using this in a lot of projects. > > Basically distro config has: > > INCOMPATIBLE_LICENSE_append += " GPLv3 GPLv3+ LGPLv3 LGPLv3+" > > and then various GPLv3 tools are allowed in build but not allowed to be > part of images: > > WHITELIST_GPL-3.0 += "binutils" > PACKAGE_EXCLUDE += "binutils-dbg binutils-staticdev binutils-dev binutils-doc > binutils-locale libbfd binutils" > > WHITELIST_GPL-3.0 += "gdb" > PACKAGE_EXCLUDE += "gdb-sdktests-dbg gdb-sdktests gdbserver gdb-dbg > gdb-staticdev gdb-dev gdb-doc gdb-locale gdb" > > WHITELIST_GPL-3.0 += "rsync" > PACKAGE_EXCLUDE += "rsync-dbg rsync-staticdev rsync-dev rsync-doc > rsync-locale rsync" > > etc etc. > > Use case is that developers can install additional GPLv3 licensed tooling if > they > need to debug something, but product images don't include them by default. > > Cheers, > > -Mikko > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161885): https://lists.openembedded.org/g/openembedded-core/message/161885 Mute This Topic: https://lists.openembedded.org/mt/89228507/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Building nativesdk package with Rust
In oe-core commit 67dd505c42 ("librsvg: do not enable nativesdk"),
nativesdk support for librsvg has been disabled:
> rust is not currently available for nativesdk builds:
> WARNING: Nothing PROVIDES 'nativesdk-libstd-rs' (but
> virtual:nativesdk:/home/pokybuild/yocto-worker/a-full/build/meta/recipes-gnome/librsvg/librsvg_2.52.0.bb
> DEPENDS on or otherwise requires it). Close matches:
> WARNING: Nothing PROVIDES 'virtual/nativesdk-x86_64-pokysdk-linux-rust' (but
> virtual:nativesdk:/home/pokybuild/yocto-worker/a-full/build/meta/recipes-gnome/librsvg/librsvg_2.52.0.bb
> DEPENDS on or otherwise requires it). Close matches:
After retrying today, only the 2nd warning was shown.
librsvg is used by graphviz which in turn is used by doxygen. I would like
to put this in my SDK again.
Is it possible to solve this problem in a foreseeable future?
regards
Christian
___
Christian
Eggers
Software Engineer
ARRI
Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Arriweg 17,
83071
Stephanskirchen
www.arri.com
+49 8036 3009-3118
cegg...@arri.de
Get all the latest information from www.arri.com, Facebook, Twitter, Instagram
and YouTube.
Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer:
HRA 57918
Persönlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer:
HRB 54477
Geschäftsführer: Dr. Michael Neuhäuser; Stephan Schenk; Walter Trauninger;
Markus Zeiler
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161887):
https://lists.openembedded.org/g/openembedded-core/message/161887
Mute This Topic: https://lists.openembedded.org/mt/89228760/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 00/46][dunfell] grub 2.04 security fixes
This series fixes a number of issues in grub 2.04. It is a part of a security series [1], except of the patch 5. The patch 5 is a dependency of patch 6, but also a bugfix on its own. While none of them has an official CVE, they fix a number of NULL pointer dereferences, memory leaks and similar issues, so seem worth having. Patches included here are also in Debian's backports [2]. [1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html [2] https://salsa.debian.org/grub-team/grub/-/tree/debian/2.04-20/debian/patches/2021-02-security Marta Rybczynska (46): grub: fix a memory leak grub: add a fix for a possible NULL dereference grub: fix a dangling memory pointer grub: fix wrong handling of argc == 0 grub: add a fix for malformed device path handling grub: fix memory leak at error in grub_efi_get_filename() grub: add a fix for a possible NULL pointer dereference grub: add a fix for unused variable in gnulib grub: fix an unitialized token in gnulib grub: add a fix a NULL pointer dereference in gnulib grub: add a fix for NULL pointer dereference grub: fix an unitialized re_token in gnulib grub: add a fix for unnecessary assignements grub: add structure initialization in zstd grub: add a missing NULL check grub: fix a memory leak grub: fix a memory leak grub: fix a memory leak grub: fix an integer overflow grub: add a fix for a length check grub: add a fix for a possible negative shift grub: add a fix for a memory leak grub: add a fix for possible integer overflows grub: fix an error check grub: add a fix for a memory leak grub: add a fix for a possible unintended sign extension grub: add a fix for a possible NULL dereference grub: add a fix for a memory leak grub: add a fix for a memory leak grub: fix a memory leak grub: remove unneeded return value grub: fix an integer overflow grub: fix multiple integer overflows grub: fix a possible integer overflow grub: test for malformed jpeg files grub: remove dead code grub: fix checking for NULL grub: add a fix for a memory leak grub: avoid a memory leak grub: add a check for a NULL pointer grub: add a fix for NULL pointer dereference grub: add a fix for an incorrect cast grub: fix incorrect use of a negative value grub: add a fix for a NULL pointer dereference grub: avoid a NULL pointer dereference grub: add a fix for a crash in scripts ...leak-when-iterating-over-mapped-memo.patch | 39 +++ ...ible-dereference-to-of-a-NULL-pointe.patch | 39 +++ ...net-tftp-Fix-dangling-memory-pointer.patch | 33 +++ ...n-parser-Fix-resource-leak-if-argc-0.patch | 50 ...formed-device-path-arithmetic-errors.patch | 235 ++ ...-kern-efi-Fix-memory-leak-on-failure.patch | 30 +++ ...ix-possible-NULL-pointer-dereference.patch | 65 + ...ulib-regexec-Resolve-unused-variable.patch | 59 + ...mp-Fix-uninitialized-token-structure.patch | 53 ...-Fix-dereference-of-a-possibly-NULL-.patch | 52 ...egexec-Fix-possible-null-dereference.patch | 53 ...b-regcomp-Fix-uninitialized-re_token.patch | 55 ...e-unnecessary-self-assignment-errors.patch | 41 +++ ...std-Initialize-seq_t-structure-fully.patch | 34 +++ ...heck-for-NULL-before-dereferencing-i.patch | 43 ...re-comp-data-is-freed-before-exiting.patch | 128 ++ ...-If-failed-then-free-vg-variable-too.patch | 28 +++ ...ory-leak-on-uninserted-lv-references.patch | 50 ...odisk-Fix-potential-integer-overflow.patch | 50 ...that-the-volume-name-length-is-valid.patch | 43 ...ix-possible-negative-shift-operation.patch | 42 ...source-leaks-while-constructing-path.patch | 121 + ...3-zfs-Fix-possible-integer-overflows.patch | 56 + ...-a-check-for-error-allocating-memory.patch | 35 +++ .../files/0025-affs-Fix-memory-leaks.patch| 82 ++ ...x-possible-unintended-sign-extension.patch | 36 +++ ...pt-mpi-Fix-possible-NULL-dereference.patch | 33 +++ ...slinux-Fix-memory-leak-while-parsing.patch | 43 ...n-Fix-leaking-of-memory-when-process.patch | 52 ...0-commands-hashsum-Fix-a-memory-leak.patch | 56 + ...move-unnecessary-return-value-of-gru.patch | 94 +++ ...bfill-Fix-potential-integer-overflow.patch | 78 ++ ...eo_fb-Fix-multiple-integer-overflows.patch | 104 ...deo_fb-Fix-possible-integer-overflow.patch | 39 +++ ...eg-Test-for-an-invalid-next-marker-r.patch | 38 +++ ...-Remove-code-that-coverity-is-flaggi.patch | 34 +++ ...ader-bsd-Check-for-NULL-arg-up-front.patch | 47 .../0038-loader-xnu-Fix-memory-leak.patch | 38 +++ ...driverkey-data-when-an-error-is-dete.patch | 77 ++ ...k-if-pointer-is-NULL-before-using-it.patch | 42 ...nstall-Fix-NULL-pointer-dereferences.patch | 41 +++ ...v-Fix-incorrect-casting-of-a-signed-.patch | 46 ...x-incorrect-use-of-a-possibly-negati.patch | 50 ...ix-NULL-dereference-in-grub_script_e.patch
[OE-core] [PATCH 02/46][dunfell] grub: add a fix for a possible NULL dereference
This fix removes a possible NULL pointer dereference in grub
networking code. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...ible-dereference-to-of-a-NULL-pointe.patch | 39 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 40 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0002-net-net-Fix-possible-dereference-to-of-a-NULL-pointe.patch
diff --git
a/meta/recipes-bsp/grub/files/0002-net-net-Fix-possible-dereference-to-of-a-NULL-pointe.patch
b/meta/recipes-bsp/grub/files/0002-net-net-Fix-possible-dereference-to-of-a-NULL-pointe.patch
new file mode 100644
index 00..d00821f5c3
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0002-net-net-Fix-possible-dereference-to-of-a-NULL-pointe.patch
@@ -0,0 +1,39 @@
+From f216a75e884ed5e4e94bf86965000dde51148f94 Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Fri, 27 Nov 2020 15:10:26 +
+Subject: [PATCH] net/net: Fix possible dereference to of a NULL pointer
+
+It is always possible that grub_zalloc() could fail, so we should check for
+a NULL return. Otherwise we run the risk of dereferencing a NULL pointer.
+
+Fixes: CID 296221
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=03f2515ae0c503406f1a99a2178405049c6555db]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/net/net.c | 9 +++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/grub-core/net/net.c b/grub-core/net/net.c
+index 38f19df..7c2cdf2 100644
+--- a/grub-core/net/net.c
b/grub-core/net/net.c
+@@ -86,8 +86,13 @@ grub_net_link_layer_add_address (struct grub_net_card *card,
+
+ /* Add sender to cache table. */
+ if (card->link_layer_table == NULL)
+-card->link_layer_table = grub_zalloc (LINK_LAYER_CACHE_SIZE
+-* sizeof (card->link_layer_table[0]));
++{
++ card->link_layer_table = grub_zalloc (LINK_LAYER_CACHE_SIZE
++ * sizeof
(card->link_layer_table[0]));
++ if (card->link_layer_table == NULL)
++ return;
++}
++
+ entry = &(card->link_layer_table[card->new_ll_entry]);
+ entry->avail = 1;
+ grub_memcpy (>ll_address, ll, sizeof (entry->ll_address));
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index a06beac5ef..2c0bff8fd0 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -48,6 +48,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://CVE-2020-25632.patch \
file://CVE-2020-25647.patch \
file://0001-mmap-Fix-memory-leak-when-iterating-over-mapped-memo.patch \
+
file://0002-net-net-Fix-possible-dereference-to-of-a-NULL-pointe.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161890):
https://lists.openembedded.org/g/openembedded-core/message/161890
Mute This Topic: https://lists.openembedded.org/mt/89229674/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 01/46][dunfell] grub: fix a memory leak
Backport a fix for a memory leak in grub_mmap_iterate(). This patch
is a part of a security series [1]
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...leak-when-iterating-over-mapped-memo.patch | 39 +++
meta/recipes-bsp/grub/grub2.inc | 3 +-
2 files changed, 41 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-bsp/grub/files/0001-mmap-Fix-memory-leak-when-iterating-over-mapped-memo.patch
diff --git
a/meta/recipes-bsp/grub/files/0001-mmap-Fix-memory-leak-when-iterating-over-mapped-memo.patch
b/meta/recipes-bsp/grub/files/0001-mmap-Fix-memory-leak-when-iterating-over-mapped-memo.patch
new file mode 100644
index 00..eaaa7effae
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0001-mmap-Fix-memory-leak-when-iterating-over-mapped-memo.patch
@@ -0,0 +1,39 @@
+From 0900f11def2e7fbb4880efff0cd9c9b32f1cdb86 Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Thu, 3 Dec 2020 14:39:45 +
+Subject: [PATCH] mmap: Fix memory leak when iterating over mapped memory
+
+When returning from grub_mmap_iterate() the memory allocated to present
+is not being released causing it to leak.
+
+Fixes: CID 96655
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=8cb2848f9699642a698af84b12ba187cab722031]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/mmap/mmap.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/grub-core/mmap/mmap.c b/grub-core/mmap/mmap.c
+index 7ebf32e..8bf235f 100644
+--- a/grub-core/mmap/mmap.c
b/grub-core/mmap/mmap.c
+@@ -270,6 +270,7 @@ grub_mmap_iterate (grub_memory_hook_t hook, void
*hook_data)
+ hook_data))
+ {
+ grub_free (ctx.scanline_events);
++grub_free (present);
+ return GRUB_ERR_NONE;
+ }
+
+@@ -282,6 +283,7 @@ grub_mmap_iterate (grub_memory_hook_t hook, void
*hook_data)
+ }
+
+ grub_free (ctx.scanline_events);
++ grub_free (present);
+ return GRUB_ERR_NONE;
+ }
+
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 9b20e1c09b..a06beac5ef 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -47,7 +47,8 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://CVE-2020-27779_7.patch \
file://CVE-2020-25632.patch \
file://CVE-2020-25647.patch \
-"
+
file://0001-mmap-Fix-memory-leak-when-iterating-over-mapped-memo.patch \
+ "
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161889):
https://lists.openembedded.org/g/openembedded-core/message/161889
Mute This Topic: https://lists.openembedded.org/mt/89229673/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 04/46][dunfell] grub: fix wrong handling of argc == 0
This change fixes wrong handling of argc == 0 causing a memory leak.
It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...n-parser-Fix-resource-leak-if-argc-0.patch | 50 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 51 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0004-kern-parser-Fix-resource-leak-if-argc-0.patch
diff --git
a/meta/recipes-bsp/grub/files/0004-kern-parser-Fix-resource-leak-if-argc-0.patch
b/meta/recipes-bsp/grub/files/0004-kern-parser-Fix-resource-leak-if-argc-0.patch
new file mode 100644
index 00..933416605c
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0004-kern-parser-Fix-resource-leak-if-argc-0.patch
@@ -0,0 +1,50 @@
+From 8861fa6226f7229105722ba669465e879b56ee2b Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Fri, 22 Jan 2021 12:32:41 +
+Subject: [PATCH] kern/parser: Fix resource leak if argc == 0
+
+After processing the command-line yet arriving at the point where we are
+setting argv, we are allocating memory, even if argc == 0, which makes
+no sense since we never put anything into the allocated argv.
+
+The solution is to simply return that we've successfully processed the
+arguments but that argc == 0, and also ensure that argv is NULL when
+we're not allocating anything in it.
+
+There are only 2 callers of this function, and both are handling a zero
+value in argc assuming nothing is allocated in argv.
+
+Fixes: CID 96680
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=d06161b035dde4769199ad65aa0a587a5920012b]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/kern/parser.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/grub-core/kern/parser.c b/grub-core/kern/parser.c
+index 619db31..d1cf061 100644
+--- a/grub-core/kern/parser.c
b/grub-core/kern/parser.c
+@@ -146,6 +146,7 @@ grub_parser_split_cmdline (const char *cmdline,
+ int i;
+
+ *argc = 0;
++ *argv = NULL;
+ do
+ {
+ if (!rd || !*rd)
+@@ -207,6 +208,10 @@ grub_parser_split_cmdline (const char *cmdline,
+ (*argc)++;
+ }
+
++ /* If there are no args, then we're done. */
++ if (!*argc)
++return 0;
++
+ /* Reserve memory for the return values. */
+ args = grub_malloc (bp - buffer);
+ if (!args)
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 678aa5c4e2..2e4e6d7ac2 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -50,6 +50,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0001-mmap-Fix-memory-leak-when-iterating-over-mapped-memo.patch \
file://0002-net-net-Fix-possible-dereference-to-of-a-NULL-pointe.patch \
file://0003-net-tftp-Fix-dangling-memory-pointer.patch \
+ file://0004-kern-parser-Fix-resource-leak-if-argc-0.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161892):
https://lists.openembedded.org/g/openembedded-core/message/161892
Mute This Topic: https://lists.openembedded.org/mt/89229676/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 05/46][dunfell] grub: add a fix for malformed device path handling
This change fixes the malformed device paths in EFI handling.
Device paths of length 4 or shorter could cause different
kinds of unexpected behaviours.
This patch is NOT a part of [1], but is a dependency of one
of the patches included in the series.
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...formed-device-path-arithmetic-errors.patch | 235 ++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 236 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0005-efi-Fix-some-malformed-device-path-arithmetic-errors.patch
diff --git
a/meta/recipes-bsp/grub/files/0005-efi-Fix-some-malformed-device-path-arithmetic-errors.patch
b/meta/recipes-bsp/grub/files/0005-efi-Fix-some-malformed-device-path-arithmetic-errors.patch
new file mode 100644
index 00..04748befc8
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0005-efi-Fix-some-malformed-device-path-arithmetic-errors.patch
@@ -0,0 +1,235 @@
+From 16a4d739b19f8680cf93a3c8fa0ae9fc1b1c310b Mon Sep 17 00:00:00 2001
+From: Peter Jones
+Date: Sun, 19 Jul 2020 16:53:27 -0400
+Subject: [PATCH] efi: Fix some malformed device path arithmetic errors
+
+Several places we take the length of a device path and subtract 4 from
+it, without ever checking that it's >= 4. There are also cases where
+this kind of malformation will result in unpredictable iteration,
+including treating the length from one dp node as the type in the next
+node. These are all errors, no matter where the data comes from.
+
+This patch adds a checking macro, GRUB_EFI_DEVICE_PATH_VALID(), which
+can be used in several places, and makes GRUB_EFI_NEXT_DEVICE_PATH()
+return NULL and GRUB_EFI_END_ENTIRE_DEVICE_PATH() evaluate as true when
+the length is too small. Additionally, it makes several places in the
+code check for and return errors in these cases.
+
+Signed-off-by: Peter Jones
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=d2cf823d0e31818d1b7a223daff6d5e006596543]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/kern/efi/efi.c | 64 +-
+ grub-core/loader/efi/chainloader.c | 13 +-
+ grub-core/loader/i386/xnu.c| 9 +++--
+ include/grub/efi/api.h | 14 ---
+ 4 files changed, 79 insertions(+), 21 deletions(-)
+
+diff --git a/grub-core/kern/efi/efi.c b/grub-core/kern/efi/efi.c
+index ad170c7..6a38080 100644
+--- a/grub-core/kern/efi/efi.c
b/grub-core/kern/efi/efi.c
+@@ -360,7 +360,7 @@ grub_efi_get_filename (grub_efi_device_path_t *dp0)
+
+ dp = dp0;
+
+- while (1)
++ while (dp)
+ {
+ grub_efi_uint8_t type = GRUB_EFI_DEVICE_PATH_TYPE (dp);
+ grub_efi_uint8_t subtype = GRUB_EFI_DEVICE_PATH_SUBTYPE (dp);
+@@ -370,9 +370,15 @@ grub_efi_get_filename (grub_efi_device_path_t *dp0)
+ if (type == GRUB_EFI_MEDIA_DEVICE_PATH_TYPE
+ && subtype == GRUB_EFI_FILE_PATH_DEVICE_PATH_SUBTYPE)
+ {
+-grub_efi_uint16_t len;
+-len = ((GRUB_EFI_DEVICE_PATH_LENGTH (dp) - 4)
+- / sizeof (grub_efi_char16_t));
++grub_efi_uint16_t len = GRUB_EFI_DEVICE_PATH_LENGTH (dp);
++
++if (len < 4)
++ {
++grub_error (GRUB_ERR_OUT_OF_RANGE,
++"malformed EFI Device Path node has length=%d", len);
++return NULL;
++ }
++len = (len - 4) / sizeof (grub_efi_char16_t);
+ filesize += GRUB_MAX_UTF8_PER_UTF16 * len + 2;
+ }
+
+@@ -388,7 +394,7 @@ grub_efi_get_filename (grub_efi_device_path_t *dp0)
+ if (!name)
+ return NULL;
+
+- while (1)
++ while (dp)
+ {
+ grub_efi_uint8_t type = GRUB_EFI_DEVICE_PATH_TYPE (dp);
+ grub_efi_uint8_t subtype = GRUB_EFI_DEVICE_PATH_SUBTYPE (dp);
+@@ -404,8 +410,15 @@ grub_efi_get_filename (grub_efi_device_path_t *dp0)
+
+ *p++ = '/';
+
+-len = ((GRUB_EFI_DEVICE_PATH_LENGTH (dp) - 4)
+- / sizeof (grub_efi_char16_t));
++len = GRUB_EFI_DEVICE_PATH_LENGTH (dp);
++if (len < 4)
++ {
++grub_error (GRUB_ERR_OUT_OF_RANGE,
++"malformed EFI Device Path node has length=%d", len);
++return NULL;
++ }
++
++len = (len - 4) / sizeof (grub_efi_char16_t);
+ fp = (grub_efi_file_path_device_path_t *) dp;
+ /* According to EFI spec Path Name is NULL terminated */
+ while (len > 0 && fp->path_name[len - 1] == 0)
+@@ -480,7 +493,26 @@ grub_efi_duplicate_device_path (const
grub_efi_device_path_t *dp)
+;
+p = GRUB_EFI_NEXT_DEVICE_PATH (p))
+ {
+- total_size += GRUB_EFI_DEVICE_PATH_LENGTH (p);
++ grub_size_t len = GRUB_EFI_DEVICE_PATH_LENGTH (p);
++
++ /*
++ * In the event that we find a node that's completely garbage, for
++ * example if we get to 0x7f 0x01 0x02 0x00 ... (EndInstance with a
[OE-core] [PATCH 03/46][dunfell] grub: fix a dangling memory pointer
This change fixes a dangling memory pointer in the grub TFTP code.
It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...net-tftp-Fix-dangling-memory-pointer.patch | 33 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 34 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0003-net-tftp-Fix-dangling-memory-pointer.patch
diff --git
a/meta/recipes-bsp/grub/files/0003-net-tftp-Fix-dangling-memory-pointer.patch
b/meta/recipes-bsp/grub/files/0003-net-tftp-Fix-dangling-memory-pointer.patch
new file mode 100644
index 00..3b4633507d
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0003-net-tftp-Fix-dangling-memory-pointer.patch
@@ -0,0 +1,33 @@
+From 09cc0df477758b60f51fbc0da1dee2f5d54c333d Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Fri, 19 Feb 2021 17:12:23 +
+Subject: [PATCH] net/tftp: Fix dangling memory pointer
+
+The static code analysis tool, Parfait, reported that the valid of
+file->data was left referencing memory that was freed by the call to
+grub_free(data) where data was initialized from file->data.
+
+To ensure that there is no unintentional access to this memory
+referenced by file->data we should set the pointer to NULL.
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=0cb838b281a68b536a09681f9557ea6a7ac5da7a]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/net/tftp.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/grub-core/net/tftp.c b/grub-core/net/tftp.c
+index 7d90bf6..f76b19f 100644
+--- a/grub-core/net/tftp.c
b/grub-core/net/tftp.c
+@@ -468,6 +468,7 @@ tftp_close (struct grub_file *file)
+ }
+ destroy_pq (data);
+ grub_free (data);
++ file->data = NULL;
+ return GRUB_ERR_NONE;
+ }
+
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 2c0bff8fd0..678aa5c4e2 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -49,6 +49,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://CVE-2020-25647.patch \
file://0001-mmap-Fix-memory-leak-when-iterating-over-mapped-memo.patch \
file://0002-net-net-Fix-possible-dereference-to-of-a-NULL-pointe.patch \
+ file://0003-net-tftp-Fix-dangling-memory-pointer.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161891):
https://lists.openembedded.org/g/openembedded-core/message/161891
Mute This Topic: https://lists.openembedded.org/mt/89229675/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 12/46][dunfell] grub: fix an unitialized re_token in gnulib
This patch adds a fix for an unitialized re_token in grub's gnulib.
It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...b-regcomp-Fix-uninitialized-re_token.patch | 55 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 56 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0012-gnulib-regcomp-Fix-uninitialized-re_token.patch
diff --git
a/meta/recipes-bsp/grub/files/0012-gnulib-regcomp-Fix-uninitialized-re_token.patch
b/meta/recipes-bsp/grub/files/0012-gnulib-regcomp-Fix-uninitialized-re_token.patch
new file mode 100644
index 00..0507e0cd66
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0012-gnulib-regcomp-Fix-uninitialized-re_token.patch
@@ -0,0 +1,55 @@
+From 512b6bb380a77233b88c84b7a712896c70281d2f Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Tue, 24 Nov 2020 18:04:22 +
+Subject: [PATCH] gnulib/regcomp: Fix uninitialized re_token
+
+This issue has been fixed in the latest version of gnulib, so to
+maintain consistency, I've backported that change rather than doing
+something different.
+
+Fixes: CID 73828
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=03477085f9a33789ba6cca7cd49ab9326a1baa0e]
+Signed-off-by: Marta Rybczynska
+---
+ conf/Makefile.extra-dist | 1 +
+ .../gnulib-patches/fix-regcomp-uninit-token.patch | 15 +++
+ 2 files changed, 16 insertions(+)
+ create mode 100644 grub-core/lib/gnulib-patches/fix-regcomp-uninit-token.patch
+
+diff --git a/conf/Makefile.extra-dist b/conf/Makefile.extra-dist
+index d27d3a9..ffe6829 100644
+--- a/conf/Makefile.extra-dist
b/conf/Makefile.extra-dist
+@@ -30,6 +30,7 @@ EXTRA_DIST += grub-core/genemuinitheader.sh
+
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-null-deref.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-null-state-deref.patch
++EXTRA_DIST += grub-core/lib/gnulib-patches/fix-regcomp-uninit-token.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-regexec-null-deref.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-uninit-structure.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-unused-value.patch
+diff --git a/grub-core/lib/gnulib-patches/fix-regcomp-uninit-token.patch
b/grub-core/lib/gnulib-patches/fix-regcomp-uninit-token.patch
+new file mode 100644
+index 000..02e0631
+--- /dev/null
b/grub-core/lib/gnulib-patches/fix-regcomp-uninit-token.patch
+@@ -0,0 +1,15 @@
++--- a/lib/regcomp.c 2020-11-24 17:06:08.159223858 +
+ b/lib/regcomp.c 2020-11-24 17:06:15.630253923 +
++@@ -3808,11 +3808,7 @@
++ create_tree (re_dfa_t *dfa, bin_tree_t *left, bin_tree_t *right,
++ re_token_type_t type)
++ {
++- re_token_t t;
++-#if defined GCC_LINT || defined lint
++- memset (, 0, sizeof t);
++-#endif
++- t.type = type;
+++ re_token_t t = { .type = type };
++ return create_token_tree (dfa, left, right, );
++ }
++
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index e7168e75ea..4ddb9fc4f1 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -58,6 +58,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0009-gnulib-regcomp-Fix-uninitialized-token-structure.patch \
file://0010-gnulib-argp-help-Fix-dereference-of-a-possibly-NULL-.patch \
file://0011-gnulib-regexec-Fix-possible-null-dereference.patch \
+ file://0012-gnulib-regcomp-Fix-uninitialized-re_token.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161900):
https://lists.openembedded.org/g/openembedded-core/message/161900
Mute This Topic: https://lists.openembedded.org/mt/89229685/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 13/46][dunfell] grub: add a fix for unnecessary assignements
Add a fix for unnecessary assignements grub's io/lzopio. This patch
is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...e-unnecessary-self-assignment-errors.patch | 41 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 42 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0013-io-lzopio-Resolve-unnecessary-self-assignment-errors.patch
diff --git
a/meta/recipes-bsp/grub/files/0013-io-lzopio-Resolve-unnecessary-self-assignment-errors.patch
b/meta/recipes-bsp/grub/files/0013-io-lzopio-Resolve-unnecessary-self-assignment-errors.patch
new file mode 100644
index 00..1190b0d090
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0013-io-lzopio-Resolve-unnecessary-self-assignment-errors.patch
@@ -0,0 +1,41 @@
+From c529ca446424f1a9c64f0007dfe31fa7645d13ac Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Wed, 21 Oct 2020 14:44:10 +
+Subject: [PATCH] io/lzopio: Resolve unnecessary self-assignment errors
+
+These 2 assignments are unnecessary since they are just assigning
+to themselves.
+
+Fixes: CID 73643
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=59666e520f44177c97b82a44c169b3b315d63b42]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/io/lzopio.c | 4
+ 1 file changed, 4 deletions(-)
+
+diff --git a/grub-core/io/lzopio.c b/grub-core/io/lzopio.c
+index 3014485..a7d4425 100644
+--- a/grub-core/io/lzopio.c
b/grub-core/io/lzopio.c
+@@ -125,8 +125,6 @@ read_block_header (struct grub_lzopio *lzopio)
+ sizeof (lzopio->block.ucheck)) !=
+ sizeof (lzopio->block.ucheck))
+ return -1;
+-
+- lzopio->block.ucheck = lzopio->block.ucheck;
+ }
+
+ /* Read checksum of compressed data. */
+@@ -143,8 +141,6 @@ read_block_header (struct grub_lzopio *lzopio)
+ sizeof (lzopio->block.ccheck)) !=
+ sizeof (lzopio->block.ccheck))
+ return -1;
+-
+-lzopio->block.ccheck = lzopio->block.ccheck;
+ }
+ }
+
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 4ddb9fc4f1..1906a28f30 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -59,6 +59,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0010-gnulib-argp-help-Fix-dereference-of-a-possibly-NULL-.patch \
file://0011-gnulib-regexec-Fix-possible-null-dereference.patch \
file://0012-gnulib-regcomp-Fix-uninitialized-re_token.patch \
+
file://0013-io-lzopio-Resolve-unnecessary-self-assignment-errors.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161901):
https://lists.openembedded.org/g/openembedded-core/message/161901
Mute This Topic: https://lists.openembedded.org/mt/89229686/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 15/46][dunfell] grub: add a missing NULL check
This fix adds a missing check for NULL pointer from an external source
in grub's kern/partition. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...heck-for-NULL-before-dereferencing-i.patch | 43 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 44 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0015-kern-partition-Check-for-NULL-before-dereferencing-i.patch
diff --git
a/meta/recipes-bsp/grub/files/0015-kern-partition-Check-for-NULL-before-dereferencing-i.patch
b/meta/recipes-bsp/grub/files/0015-kern-partition-Check-for-NULL-before-dereferencing-i.patch
new file mode 100644
index 00..af9fcd45cc
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0015-kern-partition-Check-for-NULL-before-dereferencing-i.patch
@@ -0,0 +1,43 @@
+From 0da8ef2e03a8591586b53a29af92d2ace76a04e3 Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Fri, 23 Oct 2020 09:49:59 +
+Subject: [PATCH] kern/partition: Check for NULL before dereferencing input
+ string
+
+There is the possibility that the value of str comes from an external
+source and continuing to use it before ever checking its validity is
+wrong. So, needs fixing.
+
+Additionally, drop unneeded part initialization.
+
+Fixes: CID 292444
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=bc9c468a2ce84bc767234eec888b71f1bc744fff]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/kern/partition.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/grub-core/kern/partition.c b/grub-core/kern/partition.c
+index e499147..b10a184 100644
+--- a/grub-core/kern/partition.c
b/grub-core/kern/partition.c
+@@ -109,11 +109,14 @@ grub_partition_map_probe (const grub_partition_map_t
partmap,
+ grub_partition_t
+ grub_partition_probe (struct grub_disk *disk, const char *str)
+ {
+- grub_partition_t part = 0;
++ grub_partition_t part;
+ grub_partition_t curpart = 0;
+ grub_partition_t tail;
+ const char *ptr;
+
++ if (str == NULL)
++return 0;
++
+ part = tail = disk->partition;
+
+ for (ptr = str; *ptr;)
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 7cf4d64149..94b89aa643 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -61,6 +61,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0012-gnulib-regcomp-Fix-uninitialized-re_token.patch \
file://0013-io-lzopio-Resolve-unnecessary-self-assignment-errors.patch \
file://0014-zstd-Initialize-seq_t-structure-fully.patch \
+
file://0015-kern-partition-Check-for-NULL-before-dereferencing-i.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161903):
https://lists.openembedded.org/g/openembedded-core/message/161903
Mute This Topic: https://lists.openembedded.org/mt/89229688/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 14/46][dunfell] grub: add structure initialization in zstd
This patch adds initialization of a structure in grub's zstd, which
might be left uninitialized by the compiler. It is a part of a security
series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...std-Initialize-seq_t-structure-fully.patch | 34 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 35 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0014-zstd-Initialize-seq_t-structure-fully.patch
diff --git
a/meta/recipes-bsp/grub/files/0014-zstd-Initialize-seq_t-structure-fully.patch
b/meta/recipes-bsp/grub/files/0014-zstd-Initialize-seq_t-structure-fully.patch
new file mode 100644
index 00..19d881c1ca
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0014-zstd-Initialize-seq_t-structure-fully.patch
@@ -0,0 +1,34 @@
+From f55ffe6bd8b844a8cd9956702f42ac2eb96ad56f Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Thu, 5 Nov 2020 10:29:59 +
+Subject: [PATCH] zstd: Initialize seq_t structure fully
+
+While many compilers will initialize this to zero, not all will, so it
+is better to be sure that fields not being explicitly set are at known
+values, and there is code that checks this fields value elsewhere in the
+code.
+
+Fixes: CID 292440
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=2777cf4466719921dbe4b30af358a75e7d76f217]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/lib/zstd/zstd_decompress.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/grub-core/lib/zstd/zstd_decompress.c
b/grub-core/lib/zstd/zstd_decompress.c
+index 711b5b6..e4b5670 100644
+--- a/grub-core/lib/zstd/zstd_decompress.c
b/grub-core/lib/zstd/zstd_decompress.c
+@@ -1325,7 +1325,7 @@ typedef enum { ZSTD_lo_isRegularOffset,
ZSTD_lo_isLongOffset=1 } ZSTD_longOffset
+ FORCE_INLINE_TEMPLATE seq_t
+ ZSTD_decodeSequence(seqState_t* seqState, const ZSTD_longOffset_e longOffsets)
+ {
+-seq_t seq;
++seq_t seq = {0};
+ U32 const llBits =
seqState->stateLL.table[seqState->stateLL.state].nbAdditionalBits;
+ U32 const mlBits =
seqState->stateML.table[seqState->stateML.state].nbAdditionalBits;
+ U32 const ofBits =
seqState->stateOffb.table[seqState->stateOffb.state].nbAdditionalBits;
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 1906a28f30..7cf4d64149 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -60,6 +60,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0011-gnulib-regexec-Fix-possible-null-dereference.patch \
file://0012-gnulib-regcomp-Fix-uninitialized-re_token.patch \
file://0013-io-lzopio-Resolve-unnecessary-self-assignment-errors.patch \
+ file://0014-zstd-Initialize-seq_t-structure-fully.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161902):
https://lists.openembedded.org/g/openembedded-core/message/161902
Mute This Topic: https://lists.openembedded.org/mt/89229687/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 16/46][dunfell] grub: fix a memory leak
Add a fix for a memory leak in grub's disk/ldm. It is a part of
a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...re-comp-data-is-freed-before-exiting.patch | 128 ++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 129 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0016-disk-ldm-Make-sure-comp-data-is-freed-before-exiting.patch
diff --git
a/meta/recipes-bsp/grub/files/0016-disk-ldm-Make-sure-comp-data-is-freed-before-exiting.patch
b/meta/recipes-bsp/grub/files/0016-disk-ldm-Make-sure-comp-data-is-freed-before-exiting.patch
new file mode 100644
index 00..c1687c75d0
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0016-disk-ldm-Make-sure-comp-data-is-freed-before-exiting.patch
@@ -0,0 +1,128 @@
+From 0c5d0fd796e6cafba179321de396681a493c4158 Mon Sep 17 00:00:00 2001
+From: Marco A Benatto
+Date: Mon, 7 Dec 2020 11:53:03 -0300
+Subject: [PATCH] disk/ldm: Make sure comp data is freed before exiting from
+ make_vg()
+
+Several error handling paths in make_vg() do not free comp data before
+jumping to fail2 label and returning from the function. This will leak
+memory. So, let's fix all issues of that kind.
+
+Fixes: CID 73804
+
+Signed-off-by: Marco A Benatto
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=23e39f50ca7a107f6b66396ed4d177a914dee035]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/disk/ldm.c | 51 ++--
+ 1 file changed, 44 insertions(+), 7 deletions(-)
+
+diff --git a/grub-core/disk/ldm.c b/grub-core/disk/ldm.c
+index 58f8a53..428415f 100644
+--- a/grub-core/disk/ldm.c
b/grub-core/disk/ldm.c
+@@ -554,7 +554,11 @@ make_vg (grub_disk_t disk,
+ comp->segments = grub_calloc (comp->segment_alloc,
+ sizeof (*comp->segments));
+ if (!comp->segments)
+- goto fail2;
++ {
++grub_free (comp->internal_id);
++grub_free (comp);
++goto fail2;
++ }
+ }
+ else
+ {
+@@ -562,7 +566,11 @@ make_vg (grub_disk_t disk,
+ comp->segment_count = 1;
+ comp->segments = grub_malloc (sizeof (*comp->segments));
+ if (!comp->segments)
+- goto fail2;
++ {
++grub_free (comp->internal_id);
++grub_free (comp);
++goto fail2;
++ }
+ comp->segments->start_extent = 0;
+ comp->segments->extent_count = lv->size;
+ comp->segments->layout = 0;
+@@ -574,15 +582,26 @@ make_vg (grub_disk_t disk,
+ comp->segments->layout = GRUB_RAID_LAYOUT_SYMMETRIC_MASK;
+ }
+ else
+- goto fail2;
++ {
++grub_free (comp->segments);
++grub_free (comp->internal_id);
++grub_free (comp);
++goto fail2;
++ }
+ ptr += *ptr + 1;
+ ptr++;
+ if (!(vblk[i].flags & 0x10))
+- goto fail2;
++ {
++grub_free (comp->segments);
++grub_free (comp->internal_id);
++grub_free (comp);
++goto fail2;
++ }
+ if (ptr >= vblk[i].dynamic + sizeof (vblk[i].dynamic)
+ || ptr + *ptr + 1 >= vblk[i].dynamic
+ + sizeof (vblk[i].dynamic))
+ {
++grub_free (comp->segments);
+ grub_free (comp->internal_id);
+ grub_free (comp);
+ goto fail2;
+@@ -592,6 +611,7 @@ make_vg (grub_disk_t disk,
+ if (ptr + *ptr + 1 >= vblk[i].dynamic
+ + sizeof (vblk[i].dynamic))
+ {
++grub_free (comp->segments);
+ grub_free (comp->internal_id);
+ grub_free (comp);
+ goto fail2;
+@@ -601,7 +621,12 @@ make_vg (grub_disk_t disk,
+ comp->segments->nodes = grub_calloc (comp->segments->node_alloc,
+ sizeof
(*comp->segments->nodes));
+ if (!lv->segments->nodes)
+- goto fail2;
++ {
++grub_free (comp->segments);
++grub_free (comp->internal_id);
++grub_free (comp);
++goto fail2;
++ }
+ }
+
+ if (lv->segments->node_alloc == lv->segments->node_count)
+@@ -611,11 +636,23 @@ make_vg (grub_disk_t disk,
+
+ if (grub_mul (lv->segments->node_alloc, 2,
>segments->node_alloc) ||
+ grub_mul (lv->segments->node_alloc, sizeof
(*lv->segments->nodes), ))
+- goto fail2;
++ {
++
[OE-core] [PATCH 17/46][dunfell] grub: fix a memory leak
This patch adds a fix for a memory leak in grub's disk/ldm.
It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...-If-failed-then-free-vg-variable-too.patch | 28 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 29 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0017-disk-ldm-If-failed-then-free-vg-variable-too.patch
diff --git
a/meta/recipes-bsp/grub/files/0017-disk-ldm-If-failed-then-free-vg-variable-too.patch
b/meta/recipes-bsp/grub/files/0017-disk-ldm-If-failed-then-free-vg-variable-too.patch
new file mode 100644
index 00..ecdb230f76
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0017-disk-ldm-If-failed-then-free-vg-variable-too.patch
@@ -0,0 +1,28 @@
+From 253485e8df3c9dedac848567e638157530184295 Mon Sep 17 00:00:00 2001
+From: Paulo Flabiano Smorigo
+Date: Mon, 7 Dec 2020 10:07:47 -0300
+Subject: [PATCH] disk/ldm: If failed then free vg variable too
+
+Fixes: CID 73809
+
+Signed-off-by: Paulo Flabiano Smorigo
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e0b83df5da538d2a38f770e60817b3a4b9d5b4d7]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/disk/ldm.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/grub-core/disk/ldm.c b/grub-core/disk/ldm.c
+index 428415f..54713f4 100644
+--- a/grub-core/disk/ldm.c
b/grub-core/disk/ldm.c
+@@ -199,6 +199,7 @@ make_vg (grub_disk_t disk,
+ {
+ grub_free (vg->uuid);
+ grub_free (vg->name);
++ grub_free (vg);
+ return NULL;
+ }
+ grub_memcpy (vg->uuid, label->group_guid, LDM_GUID_STRLEN);
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 479e2f71f2..a8ee0dd68a 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -63,6 +63,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0014-zstd-Initialize-seq_t-structure-fully.patch \
file://0015-kern-partition-Check-for-NULL-before-dereferencing-i.patch \
file://0016-disk-ldm-Make-sure-comp-data-is-freed-before-exiting.patch \
+ file://0017-disk-ldm-If-failed-then-free-vg-variable-too.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161905):
https://lists.openembedded.org/g/openembedded-core/message/161905
Mute This Topic: https://lists.openembedded.org/mt/89229691/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 06/46][dunfell] grub: fix memory leak at error in grub_efi_get_filename()
This change fixes a memory leak on error in grub_efi_get_filename().
It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...-kern-efi-Fix-memory-leak-on-failure.patch | 30 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 31 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0006-kern-efi-Fix-memory-leak-on-failure.patch
diff --git
a/meta/recipes-bsp/grub/files/0006-kern-efi-Fix-memory-leak-on-failure.patch
b/meta/recipes-bsp/grub/files/0006-kern-efi-Fix-memory-leak-on-failure.patch
new file mode 100644
index 00..9d7327cee6
--- /dev/null
+++ b/meta/recipes-bsp/grub/files/0006-kern-efi-Fix-memory-leak-on-failure.patch
@@ -0,0 +1,30 @@
+From d4fd0243920b71cc6e03cc0cadf23b4fe03c352f Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Thu, 5 Nov 2020 10:15:25 +
+Subject: [PATCH] kern/efi: Fix memory leak on failure
+
+Free the memory allocated to name before returning on failure.
+
+Fixes: CID 296222
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=ed286ceba6015d37a9304f04602451c47bf195d7]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/kern/efi/efi.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/grub-core/kern/efi/efi.c b/grub-core/kern/efi/efi.c
+index 6a38080..baeeef0 100644
+--- a/grub-core/kern/efi/efi.c
b/grub-core/kern/efi/efi.c
+@@ -415,6 +415,7 @@ grub_efi_get_filename (grub_efi_device_path_t *dp0)
+ {
+ grub_error (GRUB_ERR_OUT_OF_RANGE,
+ "malformed EFI Device Path node has length=%d", len);
++grub_free (name);
+ return NULL;
+ }
+
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index f7f2aa892f..04ed8b7b23 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -52,6 +52,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0003-net-tftp-Fix-dangling-memory-pointer.patch \
file://0004-kern-parser-Fix-resource-leak-if-argc-0.patch \
file://0005-efi-Fix-some-malformed-device-path-arithmetic-errors.patch \
+ file://0006-kern-efi-Fix-memory-leak-on-failure.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161894):
https://lists.openembedded.org/g/openembedded-core/message/161894
Mute This Topic: https://lists.openembedded.org/mt/89229678/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 07/46][dunfell] grub: add a fix for a possible NULL pointer dereference
This change fixes a possible NULL pointer dereference in grub's
EFI support. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...ix-possible-NULL-pointer-dereference.patch | 65 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 66 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0007-kern-efi-mm-Fix-possible-NULL-pointer-dereference.patch
diff --git
a/meta/recipes-bsp/grub/files/0007-kern-efi-mm-Fix-possible-NULL-pointer-dereference.patch
b/meta/recipes-bsp/grub/files/0007-kern-efi-mm-Fix-possible-NULL-pointer-dereference.patch
new file mode 100644
index 00..d55709406b
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0007-kern-efi-mm-Fix-possible-NULL-pointer-dereference.patch
@@ -0,0 +1,65 @@
+From be03a18b8767be50f16a845c389fd5ed29aae055 Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Fri, 11 Dec 2020 15:03:13 +
+Subject: [PATCH] kern/efi/mm: Fix possible NULL pointer dereference
+
+The model of grub_efi_get_memory_map() is that if memory_map is NULL,
+then the purpose is to discover how much memory should be allocated to
+it for the subsequent call.
+
+The problem here is that with grub_efi_is_finished set to 1, there is no
+check at all that the function is being called with a non-NULL memory_map.
+
+While this MAY be true, we shouldn't assume it.
+
+The solution to this is to behave as expected, and if memory_map is NULL,
+then don't try to use it and allow memory_map_size to be filled in, and
+return 0 as is done later in the code if the buffer is too small (or NULL).
+
+Additionally, drop unneeded ret = 1.
+
+Fixes: CID 96632
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=6aee4bfd6973c714056fb7b56890b8d524e94ee1]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/kern/efi/mm.c | 19 ++-
+ 1 file changed, 14 insertions(+), 5 deletions(-)
+
+diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
+index b02fab1..5afcef7 100644
+--- a/grub-core/kern/efi/mm.c
b/grub-core/kern/efi/mm.c
+@@ -328,15 +328,24 @@ grub_efi_get_memory_map (grub_efi_uintn_t
*memory_map_size,
+ if (grub_efi_is_finished)
+ {
+ int ret = 1;
+- if (*memory_map_size < finish_mmap_size)
++
++ if (memory_map != NULL)
+ {
+-grub_memcpy (memory_map, finish_mmap_buf, *memory_map_size);
+-ret = 0;
++if (*memory_map_size < finish_mmap_size)
++ {
++grub_memcpy (memory_map, finish_mmap_buf, *memory_map_size);
++ret = 0;
++ }
++ else
++ grub_memcpy (memory_map, finish_mmap_buf, finish_mmap_size);
+ }
+ else
+ {
+-grub_memcpy (memory_map, finish_mmap_buf, finish_mmap_size);
+-ret = 1;
++/*
++ * Incomplete, no buffer to copy into, same as
++ * GRUB_EFI_BUFFER_TOO_SMALL below.
++ */
++ret = 0;
+ }
+ *memory_map_size = finish_mmap_size;
+ if (map_key)
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 04ed8b7b23..46d65d8609 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -53,6 +53,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0004-kern-parser-Fix-resource-leak-if-argc-0.patch \
file://0005-efi-Fix-some-malformed-device-path-arithmetic-errors.patch \
file://0006-kern-efi-Fix-memory-leak-on-failure.patch \
+ file://0007-kern-efi-mm-Fix-possible-NULL-pointer-dereference.patch
\
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161895):
https://lists.openembedded.org/g/openembedded-core/message/161895
Mute This Topic: https://lists.openembedded.org/mt/89229679/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 08/46][dunfell] grub: add a fix for unused variable in gnulib
This changes adds a fix for an unused variable issue in gnulib.
It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...ulib-regexec-Resolve-unused-variable.patch | 59 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 60 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0008-gnulib-regexec-Resolve-unused-variable.patch
diff --git
a/meta/recipes-bsp/grub/files/0008-gnulib-regexec-Resolve-unused-variable.patch
b/meta/recipes-bsp/grub/files/0008-gnulib-regexec-Resolve-unused-variable.patch
new file mode 100644
index 00..74ffb559e9
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0008-gnulib-regexec-Resolve-unused-variable.patch
@@ -0,0 +1,59 @@
+From 9d36bce5d516b6379ba3a0dd1a94a9c035838827 Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Wed, 21 Oct 2020 14:41:27 +
+Subject: [PATCH] gnulib/regexec: Resolve unused variable
+
+This is a really minor issue where a variable is being assigned to but
+not checked before it is overwritten again.
+
+The reason for this issue is that we are not building with DEBUG set and
+this in turn means that the assert() that reads the value of the
+variable match_last is being processed out.
+
+The solution, move the assignment to match_last in to an ifdef DEBUG too.
+
+Fixes: CID 292459
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=a983d36bd9178d377d2072fd4b11c635fdc404b4]
+Signed-off-by: Marta Rybczynska
+---
+ conf/Makefile.extra-dist | 1 +
+ .../lib/gnulib-patches/fix-unused-value.patch | 14 ++
+ 2 files changed, 15 insertions(+)
+ create mode 100644 grub-core/lib/gnulib-patches/fix-unused-value.patch
+
+diff --git a/conf/Makefile.extra-dist b/conf/Makefile.extra-dist
+index 46c4e95..9b01152 100644
+--- a/conf/Makefile.extra-dist
b/conf/Makefile.extra-dist
+@@ -29,6 +29,7 @@ EXTRA_DIST += grub-core/genemuinit.sh
+ EXTRA_DIST += grub-core/genemuinitheader.sh
+
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-null-deref.patch
++EXTRA_DIST += grub-core/lib/gnulib-patches/fix-unused-value.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-width.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/no-abort.patch
+
+diff --git a/grub-core/lib/gnulib-patches/fix-unused-value.patch
b/grub-core/lib/gnulib-patches/fix-unused-value.patch
+new file mode 100644
+index 000..ba51f1b
+--- /dev/null
b/grub-core/lib/gnulib-patches/fix-unused-value.patch
+@@ -0,0 +1,14 @@
++--- a/lib/regexec.c 2020-10-21 14:25:35.310195912 +
+ b/lib/regexec.c 2020-10-21 14:32:07.961765604 +
++@@ -828,7 +828,11 @@
++ break;
++if (__glibc_unlikely (err != REG_NOMATCH))
++ goto free_return;
+++#ifdef DEBUG
+++ /* Only used for assertion below when DEBUG is set, otherwise
+++ it will be over-written when we loop around. */
++match_last = -1;
+++#endif
++ }
++else
++ break; /* We found a match. */
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 46d65d8609..d2a1502d56 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -54,6 +54,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0005-efi-Fix-some-malformed-device-path-arithmetic-errors.patch \
file://0006-kern-efi-Fix-memory-leak-on-failure.patch \
file://0007-kern-efi-mm-Fix-possible-NULL-pointer-dereference.patch
\
+ file://0008-gnulib-regexec-Resolve-unused-variable.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161896):
https://lists.openembedded.org/g/openembedded-core/message/161896
Mute This Topic: https://lists.openembedded.org/mt/89229680/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 09/46][dunfell] grub: fix an unitialized token in gnulib
This change adds a fix for an unitialized token structure in gnulib.
It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...mp-Fix-uninitialized-token-structure.patch | 53 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 54 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0009-gnulib-regcomp-Fix-uninitialized-token-structure.patch
diff --git
a/meta/recipes-bsp/grub/files/0009-gnulib-regcomp-Fix-uninitialized-token-structure.patch
b/meta/recipes-bsp/grub/files/0009-gnulib-regcomp-Fix-uninitialized-token-structure.patch
new file mode 100644
index 00..b6e3c7edbe
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0009-gnulib-regcomp-Fix-uninitialized-token-structure.patch
@@ -0,0 +1,53 @@
+From 2af8df02cca7fd4b584575eac304cd03fa23f5cc Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Thu, 22 Oct 2020 13:54:06 +
+Subject: [PATCH] gnulib/regcomp: Fix uninitialized token structure
+
+The code is assuming that the value of br_token.constraint was
+initialized to zero when it wasn't.
+
+While some compilers will ensure that, not all do, so it is better to
+fix this explicitly than leave it to chance.
+
+Fixes: CID 73749
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=75c3d3cec4f408848f575d6d5e30a95bd6313db0]
+Signed-off-by: Marta Rybczynska
+---
+ conf/Makefile.extra-dist | 1 +
+ .../lib/gnulib-patches/fix-uninit-structure.patch | 11 +++
+ 2 files changed, 12 insertions(+)
+ create mode 100644 grub-core/lib/gnulib-patches/fix-uninit-structure.patch
+
+diff --git a/conf/Makefile.extra-dist b/conf/Makefile.extra-dist
+index 9b01152..9e55458 100644
+--- a/conf/Makefile.extra-dist
b/conf/Makefile.extra-dist
+@@ -29,6 +29,7 @@ EXTRA_DIST += grub-core/genemuinit.sh
+ EXTRA_DIST += grub-core/genemuinitheader.sh
+
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-null-deref.patch
++EXTRA_DIST += grub-core/lib/gnulib-patches/fix-uninit-structure.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-unused-value.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-width.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/no-abort.patch
+diff --git a/grub-core/lib/gnulib-patches/fix-uninit-structure.patch
b/grub-core/lib/gnulib-patches/fix-uninit-structure.patch
+new file mode 100644
+index 000..7b4d9f6
+--- /dev/null
b/grub-core/lib/gnulib-patches/fix-uninit-structure.patch
+@@ -0,0 +1,11 @@
++--- a/lib/regcomp.c 2020-10-22 13:49:06.770168928 +
+ b/lib/regcomp.c 2020-10-22 13:50:37.026528298 +
++@@ -3662,7 +3662,7 @@
++ Idx alloc = 0;
++ #endif /* not RE_ENABLE_I18N */
++ reg_errcode_t ret;
++- re_token_t br_token;
+++ re_token_t br_token = {0};
++ bin_tree_t *tree;
++
++ sbcset = (re_bitset_ptr_t) calloc (sizeof (bitset_t), 1);
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index d2a1502d56..df2c8b8a16 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -55,6 +55,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0006-kern-efi-Fix-memory-leak-on-failure.patch \
file://0007-kern-efi-mm-Fix-possible-NULL-pointer-dereference.patch
\
file://0008-gnulib-regexec-Resolve-unused-variable.patch \
+ file://0009-gnulib-regcomp-Fix-uninitialized-token-structure.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161897):
https://lists.openembedded.org/g/openembedded-core/message/161897
Mute This Topic: https://lists.openembedded.org/mt/89229681/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 10/46][dunfell] grub: add a fix a NULL pointer dereference in gnulib
This change adds a fix for a NULL pointer dereference of state
in gnulib. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...-Fix-dereference-of-a-possibly-NULL-.patch | 52 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 53 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0010-gnulib-argp-help-Fix-dereference-of-a-possibly-NULL-.patch
diff --git
a/meta/recipes-bsp/grub/files/0010-gnulib-argp-help-Fix-dereference-of-a-possibly-NULL-.patch
b/meta/recipes-bsp/grub/files/0010-gnulib-argp-help-Fix-dereference-of-a-possibly-NULL-.patch
new file mode 100644
index 00..102a494561
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0010-gnulib-argp-help-Fix-dereference-of-a-possibly-NULL-.patch
@@ -0,0 +1,52 @@
+From eaf9da8b5f8349c51cfc89dd8e39a1a61f89790a Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Wed, 28 Oct 2020 14:43:01 +
+Subject: [PATCH] gnulib/argp-help: Fix dereference of a possibly NULL state
+
+All other instances of call to __argp_failure() where there is
+a dgettext() call is first checking whether state is NULL before
+attempting to dereference it to get the root_argp->argp_domain.
+
+Fixes: CID 292436
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=3a37bf120a9194c373257c70175cdb5b337bc107]
+Signed-off-by: Marta Rybczynska
+---
+ conf/Makefile.extra-dist | 1 +
+ .../lib/gnulib-patches/fix-null-state-deref.patch| 12
+ 2 files changed, 13 insertions(+)
+ create mode 100644 grub-core/lib/gnulib-patches/fix-null-state-deref.patch
+
+diff --git a/conf/Makefile.extra-dist b/conf/Makefile.extra-dist
+index 9e55458..96d7e69 100644
+--- a/conf/Makefile.extra-dist
b/conf/Makefile.extra-dist
+@@ -29,6 +29,7 @@ EXTRA_DIST += grub-core/genemuinit.sh
+ EXTRA_DIST += grub-core/genemuinitheader.sh
+
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-null-deref.patch
++EXTRA_DIST += grub-core/lib/gnulib-patches/fix-null-state-deref.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-uninit-structure.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-unused-value.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-width.patch
+diff --git a/grub-core/lib/gnulib-patches/fix-null-state-deref.patch
b/grub-core/lib/gnulib-patches/fix-null-state-deref.patch
+new file mode 100644
+index 000..813ec09
+--- /dev/null
b/grub-core/lib/gnulib-patches/fix-null-state-deref.patch
+@@ -0,0 +1,12 @@
++--- a/lib/argp-help.c 2020-10-28 14:32:19.189215988 +
+ b/lib/argp-help.c 2020-10-28 14:38:21.204673940 +
++@@ -145,7 +145,8 @@
++ if (*(int *)((char *)upptr + up->uparams_offs) >= upptr->rmargin)
++ {
++ __argp_failure (state, 0, 0,
++- dgettext (state->root_argp->argp_domain,
+++ dgettext (state == NULL ? NULL
+++: state->root_argp->argp_domain,
++ "\
++ ARGP_HELP_FMT: %s value is less than or equal to %s"),
++ "rmargin", up->name);
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index df2c8b8a16..94873475c1 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -56,6 +56,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0007-kern-efi-mm-Fix-possible-NULL-pointer-dereference.patch
\
file://0008-gnulib-regexec-Resolve-unused-variable.patch \
file://0009-gnulib-regcomp-Fix-uninitialized-token-structure.patch \
+
file://0010-gnulib-argp-help-Fix-dereference-of-a-possibly-NULL-.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161898):
https://lists.openembedded.org/g/openembedded-core/message/161898
Mute This Topic: https://lists.openembedded.org/mt/89229682/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 11/46][dunfell] grub: add a fix for NULL pointer dereference
Add a fix for gnulib's regexec NULL pointer dereference. This patch
a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...egexec-Fix-possible-null-dereference.patch | 53 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 54 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0011-gnulib-regexec-Fix-possible-null-dereference.patch
diff --git
a/meta/recipes-bsp/grub/files/0011-gnulib-regexec-Fix-possible-null-dereference.patch
b/meta/recipes-bsp/grub/files/0011-gnulib-regexec-Fix-possible-null-dereference.patch
new file mode 100644
index 00..4f43fcf7d5
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0011-gnulib-regexec-Fix-possible-null-dereference.patch
@@ -0,0 +1,53 @@
+From 244dc2b1f518635069a556c424b2e7627f0cf036 Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Thu, 5 Nov 2020 10:57:14 +
+Subject: [PATCH] gnulib/regexec: Fix possible null-dereference
+
+It appears to be possible that the mctx->state_log field may be NULL,
+and the name of this function, clean_state_log_if_needed(), suggests
+that it should be checking that it is valid to be cleaned before
+assuming that it does.
+
+Fixes: CID 86720
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=0b7f347638153e403ee2dd518af3ce26f4f99647]
+Signed-off-by: Marta Rybczynska
+---
+ conf/Makefile.extra-dist | 1 +
+ .../lib/gnulib-patches/fix-regexec-null-deref.patch | 12
+ 2 files changed, 13 insertions(+)
+ create mode 100644 grub-core/lib/gnulib-patches/fix-regexec-null-deref.patch
+
+diff --git a/conf/Makefile.extra-dist b/conf/Makefile.extra-dist
+index 96d7e69..d27d3a9 100644
+--- a/conf/Makefile.extra-dist
b/conf/Makefile.extra-dist
+@@ -30,6 +30,7 @@ EXTRA_DIST += grub-core/genemuinitheader.sh
+
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-null-deref.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-null-state-deref.patch
++EXTRA_DIST += grub-core/lib/gnulib-patches/fix-regexec-null-deref.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-uninit-structure.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-unused-value.patch
+ EXTRA_DIST += grub-core/lib/gnulib-patches/fix-width.patch
+diff --git a/grub-core/lib/gnulib-patches/fix-regexec-null-deref.patch
b/grub-core/lib/gnulib-patches/fix-regexec-null-deref.patch
+new file mode 100644
+index 000..db6dac9
+--- /dev/null
b/grub-core/lib/gnulib-patches/fix-regexec-null-deref.patch
+@@ -0,0 +1,12 @@
++--- a/lib/regexec.c 2020-10-21 14:25:35.310195912 +
+ b/lib/regexec.c 2020-11-05 10:55:09.621542984 +
++@@ -1692,6 +1692,9 @@
++ {
++ Idx top = mctx->state_log_top;
++
+++ if (mctx->state_log == NULL)
+++return REG_NOERROR;
+++
++ if ((next_state_log_idx >= mctx->input.bufs_len
++&& mctx->input.bufs_len < mctx->input.len)
++ || (next_state_log_idx >= mctx->input.valid_len
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 94873475c1..e7168e75ea 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -57,6 +57,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0008-gnulib-regexec-Resolve-unused-variable.patch \
file://0009-gnulib-regcomp-Fix-uninitialized-token-structure.patch \
file://0010-gnulib-argp-help-Fix-dereference-of-a-possibly-NULL-.patch \
+ file://0011-gnulib-regexec-Fix-possible-null-dereference.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161899):
https://lists.openembedded.org/g/openembedded-core/message/161899
Mute This Topic: https://lists.openembedded.org/mt/89229684/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 18/46][dunfell] grub: fix a memory leak
Add a fix for a memory leak in grub'd disk/ldm. It is a part of
a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...ory-leak-on-uninserted-lv-references.patch | 50 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 51 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0018-disk-ldm-Fix-memory-leak-on-uninserted-lv-references.patch
diff --git
a/meta/recipes-bsp/grub/files/0018-disk-ldm-Fix-memory-leak-on-uninserted-lv-references.patch
b/meta/recipes-bsp/grub/files/0018-disk-ldm-Fix-memory-leak-on-uninserted-lv-references.patch
new file mode 100644
index 00..26932f674c
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0018-disk-ldm-Fix-memory-leak-on-uninserted-lv-references.patch
@@ -0,0 +1,50 @@
+From 3e1d2f1959acbe5152cdd5818d495f6455d1a158 Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Tue, 8 Dec 2020 10:00:51 +
+Subject: [PATCH] disk/ldm: Fix memory leak on uninserted lv references
+
+The problem here is that the memory allocated to the variable lv is not
+yet inserted into the list that is being processed at the label fail2.
+
+As we can already see at line 342, which correctly frees lv before going
+to fail2, we should also be doing that at these earlier jumps to fail2.
+
+Fixes: CID 73824
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=156c281a1625dc73fd350530630c6f2d5673d4f6]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/disk/ldm.c | 10 --
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/grub-core/disk/ldm.c b/grub-core/disk/ldm.c
+index 54713f4..e82e989 100644
+--- a/grub-core/disk/ldm.c
b/grub-core/disk/ldm.c
+@@ -321,7 +321,10 @@ make_vg (grub_disk_t disk,
+ lv->visible = 1;
+ lv->segments = grub_zalloc (sizeof (*lv->segments));
+ if (!lv->segments)
+- goto fail2;
++ {
++grub_free (lv);
++goto fail2;
++ }
+ lv->segments->start_extent = 0;
+ lv->segments->type = GRUB_DISKFILTER_MIRROR;
+ lv->segments->node_count = 0;
+@@ -329,7 +332,10 @@ make_vg (grub_disk_t disk,
+ lv->segments->nodes = grub_calloc (lv->segments->node_alloc,
+sizeof (*lv->segments->nodes));
+ if (!lv->segments->nodes)
+- goto fail2;
++ {
++grub_free (lv);
++goto fail2;
++ }
+ ptr = vblk[i].dynamic;
+ if (ptr + *ptr + 1 >= vblk[i].dynamic
+ + sizeof (vblk[i].dynamic))
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index a8ee0dd68a..2fccdc2d62 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -64,6 +64,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0015-kern-partition-Check-for-NULL-before-dereferencing-i.patch \
file://0016-disk-ldm-Make-sure-comp-data-is-freed-before-exiting.patch \
file://0017-disk-ldm-If-failed-then-free-vg-variable-too.patch \
+
file://0018-disk-ldm-Fix-memory-leak-on-uninserted-lv-references.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161906):
https://lists.openembedded.org/g/openembedded-core/message/161906
Mute This Topic: https://lists.openembedded.org/mt/89229692/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 22/46][dunfell] grub: add a fix for a memory leak
This patch adds a fix for a memory leak in grub's path construction
in zfs. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...source-leaks-while-constructing-path.patch | 121 ++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 122 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0022-zfs-Fix-resource-leaks-while-constructing-path.patch
diff --git
a/meta/recipes-bsp/grub/files/0022-zfs-Fix-resource-leaks-while-constructing-path.patch
b/meta/recipes-bsp/grub/files/0022-zfs-Fix-resource-leaks-while-constructing-path.patch
new file mode 100644
index 00..5ded5520e9
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0022-zfs-Fix-resource-leaks-while-constructing-path.patch
@@ -0,0 +1,121 @@
+From 83fdffc07ec4586b375ab36189f255ffbd8f99c2 Mon Sep 17 00:00:00 2001
+From: Paulo Flabiano Smorigo
+Date: Mon, 14 Dec 2020 18:54:49 -0300
+Subject: [PATCH] zfs: Fix resource leaks while constructing path
+
+There are several exit points in dnode_get_path() that are causing possible
+memory leaks.
+
+In the while(1) the correct exit mechanism should not be to do a direct return,
+but to instead break out of the loop, setting err first if it is not already
set.
+
+The reason behind this is that the dnode_path is a linked list, and while doing
+through this loop, it is being allocated and built up - the only way to
+correctly unravel it is to traverse it, which is what is being done at the end
+of the function outside of the loop.
+
+Several of the existing exit points correctly did a break, but not all so this
+change makes that more consistent and should resolve the leaking of memory as
+found by Coverity.
+
+Fixes: CID 73741
+
+Signed-off-by: Paulo Flabiano Smorigo
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=89bdab965805e8d54d7f75349024e1a11cbe2eb8]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/fs/zfs/zfs.c | 30 +-
+ 1 file changed, 21 insertions(+), 9 deletions(-)
+
+diff --git a/grub-core/fs/zfs/zfs.c b/grub-core/fs/zfs/zfs.c
+index 0c42cba..9087a72 100644
+--- a/grub-core/fs/zfs/zfs.c
b/grub-core/fs/zfs/zfs.c
+@@ -2836,8 +2836,8 @@ dnode_get_path (struct subvolume *subvol, const char
*path_in, dnode_end_t *dn,
+
+ if (dnode_path->dn.dn.dn_type != DMU_OT_DIRECTORY_CONTENTS)
+ {
+-grub_free (path_buf);
+-return grub_error (GRUB_ERR_BAD_FILE_TYPE, N_("not a directory"));
++err = grub_error (GRUB_ERR_BAD_FILE_TYPE, N_("not a directory"));
++break;
+ }
+ err = zap_lookup (&(dnode_path->dn), cname, ,
+ data, subvol->case_insensitive);
+@@ -2879,11 +2879,18 @@ dnode_get_path (struct subvolume *subvol, const char
*path_in, dnode_end_t *dn,
+ << SPA_MINBLOCKSHIFT);
+
+ if (blksz == 0)
+- return grub_error(GRUB_ERR_BAD_FS, "0-sized block");
++{
++ err = grub_error (GRUB_ERR_BAD_FS, "0-sized block");
++ break;
++}
+
+ sym_value = grub_malloc (sym_sz);
+ if (!sym_value)
+- return grub_errno;
++ {
++err = grub_errno;
++break;
++ }
++
+ for (block = 0; block < (sym_sz + blksz - 1) / blksz; block++)
+ {
+ void *t;
+@@ -2893,7 +2900,7 @@ dnode_get_path (struct subvolume *subvol, const char
*path_in, dnode_end_t *dn,
+ if (err)
+ {
+ grub_free (sym_value);
+-return err;
++break;
+ }
+
+ movesize = sym_sz - block * blksz;
+@@ -2903,6 +2910,8 @@ dnode_get_path (struct subvolume *subvol, const char
*path_in, dnode_end_t *dn,
+ grub_memcpy (sym_value + block * blksz, t, movesize);
+ grub_free (t);
+ }
++ if (err)
++break;
+ free_symval = 1;
+ }
+ path = path_buf = grub_malloc (sym_sz + grub_strlen (oldpath) + 1);
+@@ -2911,7 +2920,8 @@ dnode_get_path (struct subvolume *subvol, const char
*path_in, dnode_end_t *dn,
+ grub_free (oldpathbuf);
+ if (free_symval)
+ grub_free (sym_value);
+-return grub_errno;
++err = grub_errno;
++break;
+ }
+ grub_memcpy (path, sym_value, sym_sz);
+ if (free_symval)
+@@ -2949,11 +2959,12 @@ dnode_get_path (struct subvolume *subvol, const char
*path_in, dnode_end_t *dn,
+
+ err = zio_read (bp, dnode_path->dn.endian, , NULL, data);
+ if (err)
+- return err;
++ break;
+ }
+
[OE-core] [PATCH 23/46][dunfell] grub: add a fix for possible integer overflows
This patch adds a fix for a possible integer overflows in grub's zfs.
It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...3-zfs-Fix-possible-integer-overflows.patch | 56 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 57 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0023-zfs-Fix-possible-integer-overflows.patch
diff --git
a/meta/recipes-bsp/grub/files/0023-zfs-Fix-possible-integer-overflows.patch
b/meta/recipes-bsp/grub/files/0023-zfs-Fix-possible-integer-overflows.patch
new file mode 100644
index 00..8df758b41f
--- /dev/null
+++ b/meta/recipes-bsp/grub/files/0023-zfs-Fix-possible-integer-overflows.patch
@@ -0,0 +1,56 @@
+From ec35d862f3567671048aa0d0d8ad1ded1fd25336 Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Tue, 8 Dec 2020 22:17:04 +
+Subject: [PATCH] zfs: Fix possible integer overflows
+
+In all cases the problem is that the value being acted upon by
+a left-shift is a 32-bit number which is then being used in the
+context of a 64-bit number.
+
+To avoid overflow we ensure that the number being shifted is 64-bit
+before the shift is done.
+
+Fixes: CID 73684, CID 73695, CID 73764
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=302c12ff5714bc455949117c1c9548ccb324d55b]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/fs/zfs/zfs.c | 8
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/grub-core/fs/zfs/zfs.c b/grub-core/fs/zfs/zfs.c
+index 9087a72..b078ccc 100644
+--- a/grub-core/fs/zfs/zfs.c
b/grub-core/fs/zfs/zfs.c
+@@ -564,7 +564,7 @@ find_bestub (uberblock_phys_t * ub_array,
+ ubptr = (uberblock_phys_t *) ((grub_properly_aligned_t *) ub_array
+ + ((i << ub_shift)
+ / sizeof (grub_properly_aligned_t)));
+- err = uberblock_verify (ubptr, offset, 1 << ub_shift);
++ err = uberblock_verify (ubptr, offset, (grub_size_t) 1 << ub_shift);
+ if (err)
+ {
+ grub_errno = GRUB_ERR_NONE;
+@@ -1543,7 +1543,7 @@ read_device (grub_uint64_t offset, struct
grub_zfs_device_desc *desc,
+
+ high = grub_divmod64 ((offset >> desc->ashift) + c,
+ desc->n_children, );
+- csize = bsize << desc->ashift;
++ csize = (grub_size_t) bsize << desc->ashift;
+ if (csize > len)
+ csize = len;
+
+@@ -1635,8 +1635,8 @@ read_device (grub_uint64_t offset, struct
grub_zfs_device_desc *desc,
+
+ while (len > 0)
+ {
+- grub_size_t csize;
+- csize = ((s / (desc->n_children - desc->nparity))
++ grub_size_t csize = s;
++ csize = ((csize / (desc->n_children - desc->nparity))
+<< desc->ashift);
+ if (csize > len)
+ csize = len;
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 1630235edd..9158fc7f50 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -69,6 +69,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0020-hfsplus-Check-that-the-volume-name-length-is-valid.patch \
file://0021-zfs-Fix-possible-negative-shift-operation.patch \
file://0022-zfs-Fix-resource-leaks-while-constructing-path.patch \
+ file://0023-zfs-Fix-possible-integer-overflows.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161911):
https://lists.openembedded.org/g/openembedded-core/message/161911
Mute This Topic: https://lists.openembedded.org/mt/89229697/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 24/46][dunfell] grub: fix an error check
This patch fixes an error check in grub's zfsinfo. It is a part of
a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...-a-check-for-error-allocating-memory.patch | 35 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 36 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0024-zfsinfo-Correct-a-check-for-error-allocating-memory.patch
diff --git
a/meta/recipes-bsp/grub/files/0024-zfsinfo-Correct-a-check-for-error-allocating-memory.patch
b/meta/recipes-bsp/grub/files/0024-zfsinfo-Correct-a-check-for-error-allocating-memory.patch
new file mode 100644
index 00..555dc19168
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0024-zfsinfo-Correct-a-check-for-error-allocating-memory.patch
@@ -0,0 +1,35 @@
+From b085da8efda9b81f94aa197ee045226563554fdf Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Thu, 26 Nov 2020 10:56:45 +
+Subject: [PATCH] zfsinfo: Correct a check for error allocating memory
+
+While arguably the check for grub_errno is correct, we should really be
+checking the return value from the function since it is always possible
+that grub_errno was set elsewhere, making this code behave incorrectly.
+
+Fixes: CID 73668
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=7aab03418ec6a9b991aa44416cb2585aff4e7972]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/fs/zfs/zfsinfo.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/grub-core/fs/zfs/zfsinfo.c b/grub-core/fs/zfs/zfsinfo.c
+index c8a28ac..bf29180 100644
+--- a/grub-core/fs/zfs/zfsinfo.c
b/grub-core/fs/zfs/zfsinfo.c
+@@ -358,8 +358,8 @@ grub_cmd_zfs_bootfs (grub_command_t cmd __attribute__
((unused)), int argc,
+ return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("one argument expected"));
+
+ devname = grub_file_get_device_name (args[0]);
+- if (grub_errno)
+-return grub_errno;
++ if (devname == NULL)
++return GRUB_ERR_OUT_OF_MEMORY;
+
+ dev = grub_device_open (devname);
+ grub_free (devname);
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 9158fc7f50..a660c069db 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -70,6 +70,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0021-zfs-Fix-possible-negative-shift-operation.patch \
file://0022-zfs-Fix-resource-leaks-while-constructing-path.patch \
file://0023-zfs-Fix-possible-integer-overflows.patch \
+
file://0024-zfsinfo-Correct-a-check-for-error-allocating-memory.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161912):
https://lists.openembedded.org/g/openembedded-core/message/161912
Mute This Topic: https://lists.openembedded.org/mt/89229698/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 25/46][dunfell] grub: add a fix for a memory leak
This patch fixes a memory leak in grub's affs. It is a part of
a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
.../files/0025-affs-Fix-memory-leaks.patch| 82 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 83 insertions(+)
create mode 100644 meta/recipes-bsp/grub/files/0025-affs-Fix-memory-leaks.patch
diff --git a/meta/recipes-bsp/grub/files/0025-affs-Fix-memory-leaks.patch
b/meta/recipes-bsp/grub/files/0025-affs-Fix-memory-leaks.patch
new file mode 100644
index 00..435130516c
--- /dev/null
+++ b/meta/recipes-bsp/grub/files/0025-affs-Fix-memory-leaks.patch
@@ -0,0 +1,82 @@
+From 929c2ce8214c53cb95abff57a89556cd18444097 Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Thu, 26 Nov 2020 12:48:07 +
+Subject: [PATCH] affs: Fix memory leaks
+
+The node structure reference is being allocated but not freed if it
+reaches the end of the function. If any of the hooks had returned
+a non-zero value, then node would have been copied in to the context
+reference, but otherwise node is not stored and should be freed.
+
+Similarly, the call to grub_affs_create_node() replaces the allocated
+memory in node with a newly allocated structure, leaking the existing
+memory pointed by node.
+
+Finally, when dir->parent is set, then we again replace node with newly
+allocated memory, which seems unnecessary when we copy in the values
+from dir->parent immediately after.
+
+Fixes: CID 73759
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=178ac5107389f8e5b32489d743d6824a5ebf342a]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/fs/affs.c | 18 --
+ 1 file changed, 8 insertions(+), 10 deletions(-)
+
+diff --git a/grub-core/fs/affs.c b/grub-core/fs/affs.c
+index 220b371..230e26a 100644
+--- a/grub-core/fs/affs.c
b/grub-core/fs/affs.c
+@@ -400,12 +400,12 @@ grub_affs_iterate_dir (grub_fshelp_node_t dir,
+ {
+ unsigned int i;
+ struct grub_affs_file file;
+- struct grub_fshelp_node *node = 0;
++ struct grub_fshelp_node *node, *orig_node;
+ struct grub_affs_data *data = dir->data;
+ grub_uint32_t *hashtable;
+
+ /* Create the directory entries for `.' and `..'. */
+- node = grub_zalloc (sizeof (*node));
++ node = orig_node = grub_zalloc (sizeof (*node));
+ if (!node)
+ return 1;
+
+@@ -414,9 +414,6 @@ grub_affs_iterate_dir (grub_fshelp_node_t dir,
+ return 1;
+ if (dir->parent)
+ {
+- node = grub_zalloc (sizeof (*node));
+- if (!node)
+- return 1;
+ *node = *dir->parent;
+ if (hook ("..", GRUB_FSHELP_DIR, node, hook_data))
+ return 1;
+@@ -456,17 +453,18 @@ grub_affs_iterate_dir (grub_fshelp_node_t dir,
+
+ if (grub_affs_create_node (dir, hook, hook_data, , ,
+next, ))
+- return 1;
++ {
++/* Node has been replaced in function. */
++grub_free (orig_node);
++return 1;
++ }
+
+ next = grub_be_to_cpu32 (file.next);
+ }
+ }
+
+- grub_free (hashtable);
+- return 0;
+-
+ fail:
+- grub_free (node);
++ grub_free (orig_node);
+ grub_free (hashtable);
+ return 0;
+ }
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index a660c069db..13e2b1600d 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -71,6 +71,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0022-zfs-Fix-resource-leaks-while-constructing-path.patch \
file://0023-zfs-Fix-possible-integer-overflows.patch \
file://0024-zfsinfo-Correct-a-check-for-error-allocating-memory.patch \
+ file://0025-affs-Fix-memory-leaks.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161913):
https://lists.openembedded.org/g/openembedded-core/message/161913
Mute This Topic: https://lists.openembedded.org/mt/89229699/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 26/46][dunfell] grub: add a fix for a possible unintended sign extension
This patch fixes a possible unintended sign extension in grub's
libgcrypt/mpi. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...x-possible-unintended-sign-extension.patch | 36 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 37 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0026-libgcrypt-mpi-Fix-possible-unintended-sign-extension.patch
diff --git
a/meta/recipes-bsp/grub/files/0026-libgcrypt-mpi-Fix-possible-unintended-sign-extension.patch
b/meta/recipes-bsp/grub/files/0026-libgcrypt-mpi-Fix-possible-unintended-sign-extension.patch
new file mode 100644
index 00..f500f1a296
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0026-libgcrypt-mpi-Fix-possible-unintended-sign-extension.patch
@@ -0,0 +1,36 @@
+From 9b16d7bcad1c7fea7f26eb2fb3af1a5ca70ba34e Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Tue, 3 Nov 2020 16:43:37 +
+Subject: [PATCH] libgcrypt/mpi: Fix possible unintended sign extension
+
+The array of unsigned char gets promoted to a signed 32-bit int before
+it is finally promoted to a size_t. There is the possibility that this
+may result in the signed-bit being set for the intermediate signed
+32-bit int. We should ensure that the promotion is to the correct type
+before we bitwise-OR the values.
+
+Fixes: CID 96697
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e8814c811132a70f9b55418f7567378a34ad3883]
+Signed-off-by: Marta Rybczynska
+
+---
+ grub-core/lib/libgcrypt/mpi/mpicoder.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/grub-core/lib/libgcrypt/mpi/mpicoder.c
b/grub-core/lib/libgcrypt/mpi/mpicoder.c
+index a3435ed..7ecad27 100644
+--- a/grub-core/lib/libgcrypt/mpi/mpicoder.c
b/grub-core/lib/libgcrypt/mpi/mpicoder.c
+@@ -458,7 +458,7 @@ gcry_mpi_scan (struct gcry_mpi **ret_mpi, enum
gcry_mpi_format format,
+ if (len && len < 4)
+ return gcry_error (GPG_ERR_TOO_SHORT);
+
+- n = (s[0] << 24 | s[1] << 16 | s[2] << 8 | s[3]);
++ n = ((size_t)s[0] << 24 | (size_t)s[1] << 16 | (size_t)s[2] << 8 |
(size_t)s[3]);
+ s += 4;
+ if (len)
+ len -= 4;
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 13e2b1600d..be35ac04ef 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -72,6 +72,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0023-zfs-Fix-possible-integer-overflows.patch \
file://0024-zfsinfo-Correct-a-check-for-error-allocating-memory.patch \
file://0025-affs-Fix-memory-leaks.patch \
+
file://0026-libgcrypt-mpi-Fix-possible-unintended-sign-extension.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161914):
https://lists.openembedded.org/g/openembedded-core/message/161914
Mute This Topic: https://lists.openembedded.org/mt/89229700/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 27/46][dunfell] grub: add a fix for a possible NULL dereference
This patch adds a fix for a possible NULL dereference in grub's
libgcrypt/mpi. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...pt-mpi-Fix-possible-NULL-dereference.patch | 33 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 34 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0027-libgcrypt-mpi-Fix-possible-NULL-dereference.patch
diff --git
a/meta/recipes-bsp/grub/files/0027-libgcrypt-mpi-Fix-possible-NULL-dereference.patch
b/meta/recipes-bsp/grub/files/0027-libgcrypt-mpi-Fix-possible-NULL-dereference.patch
new file mode 100644
index 00..08299d021e
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0027-libgcrypt-mpi-Fix-possible-NULL-dereference.patch
@@ -0,0 +1,33 @@
+From d26c8771293637b0465f2cb67d97cb58bacc62da Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Thu, 26 Nov 2020 10:41:54 +
+Subject: [PATCH] libgcrypt/mpi: Fix possible NULL dereference
+
+The code in gcry_mpi_scan() assumes that buffer is not NULL, but there
+is no explicit check for that, so we add one.
+
+Fixes: CID 73757
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=ae0f3fabeba7b393113d5dc185b6aff9b728136d]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/lib/libgcrypt/mpi/mpicoder.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/grub-core/lib/libgcrypt/mpi/mpicoder.c
b/grub-core/lib/libgcrypt/mpi/mpicoder.c
+index 7ecad27..6fe3891 100644
+--- a/grub-core/lib/libgcrypt/mpi/mpicoder.c
b/grub-core/lib/libgcrypt/mpi/mpicoder.c
+@@ -379,6 +379,9 @@ gcry_mpi_scan (struct gcry_mpi **ret_mpi, enum
gcry_mpi_format format,
+ unsigned int len;
+ int secure = (buffer && gcry_is_secure (buffer));
+
++ if (!buffer)
++return gcry_error (GPG_ERR_INV_ARG);
++
+ if (format == GCRYMPI_FMT_SSH)
+ len = 0;
+ else
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index be35ac04ef..ef409bdd6a 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -73,6 +73,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0024-zfsinfo-Correct-a-check-for-error-allocating-memory.patch \
file://0025-affs-Fix-memory-leaks.patch \
file://0026-libgcrypt-mpi-Fix-possible-unintended-sign-extension.patch \
+ file://0027-libgcrypt-mpi-Fix-possible-NULL-dereference.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161915):
https://lists.openembedded.org/g/openembedded-core/message/161915
Mute This Topic: https://lists.openembedded.org/mt/89229701/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 29/46][dunfell] grub: add a fix for a memory leak
This patch adds a fix for a memory leak in grub's normal/completion.
It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...n-Fix-leaking-of-memory-when-process.patch | 52 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 53 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0029-normal-completion-Fix-leaking-of-memory-when-process.patch
diff --git
a/meta/recipes-bsp/grub/files/0029-normal-completion-Fix-leaking-of-memory-when-process.patch
b/meta/recipes-bsp/grub/files/0029-normal-completion-Fix-leaking-of-memory-when-process.patch
new file mode 100644
index 00..8a26e5bc5b
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0029-normal-completion-Fix-leaking-of-memory-when-process.patch
@@ -0,0 +1,52 @@
+From 2367049d2021e00d82d19cee923e06a4b04ebc30 Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Fri, 4 Dec 2020 18:56:48 +
+Subject: [PATCH] normal/completion: Fix leaking of memory when processing a
+ completion
+
+It is possible for the code to reach the end of the function without
+freeing the memory allocated to argv and argc still to be 0.
+
+We should always call grub_free(argv). The grub_free() will handle
+a NULL argument correctly if it reaches that code without the memory
+being allocated.
+
+Fixes: CID 96672
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=9213575b7a95b514bce80be5964a28d407d7d56d]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/normal/completion.c | 10 --
+ 1 file changed, 4 insertions(+), 6 deletions(-)
+
+diff --git a/grub-core/normal/completion.c b/grub-core/normal/completion.c
+index 5961028..46e473c 100644
+--- a/grub-core/normal/completion.c
b/grub-core/normal/completion.c
+@@ -400,8 +400,8 @@ char *
+ grub_normal_do_completion (char *buf, int *restore,
+ void (*hook) (const char *, grub_completion_type_t,
int))
+ {
+- int argc;
+- char **argv;
++ int argc = 0;
++ char **argv = NULL;
+
+ /* Initialize variables. */
+ match = 0;
+@@ -516,10 +516,8 @@ grub_normal_do_completion (char *buf, int *restore,
+
+ fail:
+ if (argc != 0)
+-{
+- grub_free (argv[0]);
+- grub_free (argv);
+-}
++grub_free (argv[0]);
++ grub_free (argv);
+ grub_free (match);
+ grub_errno = GRUB_ERR_NONE;
+
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index c965f0fd15..1460e559b9 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -75,6 +75,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0026-libgcrypt-mpi-Fix-possible-unintended-sign-extension.patch \
file://0027-libgcrypt-mpi-Fix-possible-NULL-dereference.patch \
file://0028-syslinux-Fix-memory-leak-while-parsing.patch \
+
file://0029-normal-completion-Fix-leaking-of-memory-when-process.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161917):
https://lists.openembedded.org/g/openembedded-core/message/161917
Mute This Topic: https://lists.openembedded.org/mt/89229703/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 28/46][dunfell] grub: add a fix for a memory leak
This patch fixes a memory leak in grub's syslinux parsing. It is a part of
a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...slinux-Fix-memory-leak-while-parsing.patch | 43 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 44 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0028-syslinux-Fix-memory-leak-while-parsing.patch
diff --git
a/meta/recipes-bsp/grub/files/0028-syslinux-Fix-memory-leak-while-parsing.patch
b/meta/recipes-bsp/grub/files/0028-syslinux-Fix-memory-leak-while-parsing.patch
new file mode 100644
index 00..d8c21d88f7
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0028-syslinux-Fix-memory-leak-while-parsing.patch
@@ -0,0 +1,43 @@
+From ea12feb69b6af93c7e2fa03df7ac3bd1f4edd599 Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Thu, 26 Nov 2020 15:31:53 +
+Subject: [PATCH] syslinux: Fix memory leak while parsing
+
+In syslinux_parse_real() the 2 points where return is being called
+didn't release the memory stored in buf which is no longer required.
+
+Fixes: CID 176634
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=95bc016dba94cab3d398dd74160665915cd08ad6]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/lib/syslinux_parse.c | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/grub-core/lib/syslinux_parse.c b/grub-core/lib/syslinux_parse.c
+index 4afa992..3acc6b4 100644
+--- a/grub-core/lib/syslinux_parse.c
b/grub-core/lib/syslinux_parse.c
+@@ -737,7 +737,10 @@ syslinux_parse_real (struct syslinux_menu *menu)
+ && grub_strncasecmp ("help", ptr3, ptr4 - ptr3) == 0))
+ {
+ if (helptext (ptr5, file, menu))
+- return 1;
++ {
++grub_free (buf);
++return 1;
++ }
+ continue;
+ }
+
+@@ -757,6 +760,7 @@ syslinux_parse_real (struct syslinux_menu *menu)
+ }
+ fail:
+ grub_file_close (file);
++ grub_free (buf);
+ return err;
+ }
+
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index ef409bdd6a..c965f0fd15 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -74,6 +74,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0025-affs-Fix-memory-leaks.patch \
file://0026-libgcrypt-mpi-Fix-possible-unintended-sign-extension.patch \
file://0027-libgcrypt-mpi-Fix-possible-NULL-dereference.patch \
+ file://0028-syslinux-Fix-memory-leak-while-parsing.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161916):
https://lists.openembedded.org/g/openembedded-core/message/161916
Mute This Topic: https://lists.openembedded.org/mt/89229702/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 31/46][dunfell] grub: remove unneeded return value
This patch removes an uneeded return value in grub's (static)
grub_video_gop_fill_mode_info(). It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...move-unnecessary-return-value-of-gru.patch | 94 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 95 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0031-video-efi_gop-Remove-unnecessary-return-value-of-gru.patch
diff --git
a/meta/recipes-bsp/grub/files/0031-video-efi_gop-Remove-unnecessary-return-value-of-gru.patch
b/meta/recipes-bsp/grub/files/0031-video-efi_gop-Remove-unnecessary-return-value-of-gru.patch
new file mode 100644
index 00..7e4e951245
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0031-video-efi_gop-Remove-unnecessary-return-value-of-gru.patch
@@ -0,0 +1,94 @@
+From 2a1e5659763790201a342f8a897c8c9d8d91b1cc Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Tue, 8 Dec 2020 21:14:31 +
+Subject: [PATCH] video/efi_gop: Remove unnecessary return value of
+ grub_video_gop_fill_mode_info()
+
+The return value of grub_video_gop_fill_mode_info() is never able to be
+anything other than GRUB_ERR_NONE. So, rather than continue to return
+a value and checking it each time, it is more correct to redefine the
+function to not return anything and remove checks of its return value
+altogether.
+
+Fixes: CID 96701
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=fc5951d3b1616055ef81a019a5affc09d13344d0]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/video/efi_gop.c | 25 ++---
+ 1 file changed, 6 insertions(+), 19 deletions(-)
+
+diff --git a/grub-core/video/efi_gop.c b/grub-core/video/efi_gop.c
+index 7f9d1c2..db2ee98 100644
+--- a/grub-core/video/efi_gop.c
b/grub-core/video/efi_gop.c
+@@ -227,7 +227,7 @@ grub_video_gop_fill_real_mode_info (unsigned mode,
+ return GRUB_ERR_NONE;
+ }
+
+-static grub_err_t
++static void
+ grub_video_gop_fill_mode_info (unsigned mode,
+ struct grub_efi_gop_mode_info *in,
+ struct grub_video_mode_info *out)
+@@ -252,8 +252,6 @@ grub_video_gop_fill_mode_info (unsigned mode,
+ out->blit_format = GRUB_VIDEO_BLIT_FORMAT_BGRA_;
+ out->mode_type |= (GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED
+| GRUB_VIDEO_MODE_TYPE_UPDATING_SWAP);
+-
+- return GRUB_ERR_NONE;
+ }
+
+ static int
+@@ -266,7 +264,6 @@ grub_video_gop_iterate (int (*hook) (const struct
grub_video_mode_info *info, vo
+ grub_efi_uintn_t size;
+ grub_efi_status_t status;
+ struct grub_efi_gop_mode_info *info = NULL;
+- grub_err_t err;
+ struct grub_video_mode_info mode_info;
+
+ status = efi_call_4 (gop->query_mode, gop, mode, , );
+@@ -277,12 +274,7 @@ grub_video_gop_iterate (int (*hook) (const struct
grub_video_mode_info *info, vo
+ continue;
+ }
+
+- err = grub_video_gop_fill_mode_info (mode, info, _info);
+- if (err)
+- {
+-grub_errno = GRUB_ERR_NONE;
+-continue;
+- }
++ grub_video_gop_fill_mode_info (mode, info, _info);
+ if (hook (_info, hook_arg))
+ return 1;
+ }
+@@ -466,13 +458,8 @@ grub_video_gop_setup (unsigned int width, unsigned int
height,
+
+ info = gop->mode->info;
+
+- err = grub_video_gop_fill_mode_info (gop->mode->mode, info,
+- _info);
+- if (err)
+-{
+- grub_dprintf ("video", "GOP: couldn't fill mode info\n");
+- return err;
+-}
++ grub_video_gop_fill_mode_info (gop->mode->mode, info,
++ _info);
+
+ framebuffer.ptr = (void *) (grub_addr_t) gop->mode->fb_base;
+ framebuffer.offscreen
+@@ -486,8 +473,8 @@ grub_video_gop_setup (unsigned int width, unsigned int
height,
+ {
+ grub_dprintf ("video", "GOP: couldn't allocate shadow\n");
+ grub_errno = 0;
+- err = grub_video_gop_fill_mode_info (gop->mode->mode, info,
+- _info);
++ grub_video_gop_fill_mode_info (gop->mode->mode, info,
++ _info);
+ buffer = framebuffer.ptr;
+ }
+
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index d18e329b96..24a269d90d 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -77,6 +77,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0028-syslinux-Fix-memory-leak-while-parsing.patch \
file://0029-normal-completion-Fix-leaking-of-memory-when-process.patch \
file://0030-commands-hashsum-Fix-a-memory-leak.patch \
+
file://0031-video-efi_gop-Remove-unnecessary-return-value-of-gru.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
[OE-core] [PATCH 32/46][dunfell] grub: fix an integer overflow
This patch adds a fix for a potential integer overflow in grub's
video/fb/fbfill. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...bfill-Fix-potential-integer-overflow.patch | 78 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 79 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0032-video-fb-fbfill-Fix-potential-integer-overflow.patch
diff --git
a/meta/recipes-bsp/grub/files/0032-video-fb-fbfill-Fix-potential-integer-overflow.patch
b/meta/recipes-bsp/grub/files/0032-video-fb-fbfill-Fix-potential-integer-overflow.patch
new file mode 100644
index 00..8165ea3f71
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0032-video-fb-fbfill-Fix-potential-integer-overflow.patch
@@ -0,0 +1,78 @@
+From 99ecf5a44b99d529a6405fe276bedcefa3657a0a Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Wed, 4 Nov 2020 15:10:51 +
+Subject: [PATCH] video/fb/fbfill: Fix potential integer overflow
+
+The multiplication of 2 unsigned 32-bit integers may overflow before
+promotion to unsigned 64-bit. We should ensure that the multiplication
+is done with overflow detection. Additionally, use grub_sub() for
+subtraction.
+
+Fixes: CID 73640, CID 73697, CID 73702, CID 73823
+
+Signed-off-by: Darren Kenny
+Signed-off-by: Marco A Benatto
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=7ce3259f67ac2cd93acb0ec0080c24b3b69e66c6]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/video/fb/fbfill.c | 17 +
+ 1 file changed, 13 insertions(+), 4 deletions(-)
+
+diff --git a/grub-core/video/fb/fbfill.c b/grub-core/video/fb/fbfill.c
+index 11816d0..a37acd1 100644
+--- a/grub-core/video/fb/fbfill.c
b/grub-core/video/fb/fbfill.c
+@@ -31,6 +31,7 @@
+ #include
+ #include
+ #include
++#include
+ #include
+
+ /* Generic filler that works for every supported mode. */
+@@ -61,7 +62,9 @@ grub_video_fbfill_direct32 (struct grub_video_fbblit_info
*dst,
+
+ /* Calculate the number of bytes to advance from the end of one line
+ to the beginning of the next line. */
+- rowskip = dst->mode_info->pitch - dst->mode_info->bytes_per_pixel * width;
++ if (grub_mul (dst->mode_info->bytes_per_pixel, width, ) ||
++ grub_sub (dst->mode_info->pitch, rowskip, ))
++return;
+
+ /* Get the start address. */
+ dstptr = grub_video_fb_get_video_ptr (dst, x, y);
+@@ -98,7 +101,9 @@ grub_video_fbfill_direct24 (struct grub_video_fbblit_info
*dst,
+ #endif
+ /* Calculate the number of bytes to advance from the end of one line
+ to the beginning of the next line. */
+- rowskip = dst->mode_info->pitch - dst->mode_info->bytes_per_pixel * width;
++ if (grub_mul (dst->mode_info->bytes_per_pixel, width, ) ||
++ grub_sub (dst->mode_info->pitch, rowskip, ))
++return;
+
+ /* Get the start address. */
+ dstptr = grub_video_fb_get_video_ptr (dst, x, y);
+@@ -131,7 +136,9 @@ grub_video_fbfill_direct16 (struct grub_video_fbblit_info
*dst,
+
+ /* Calculate the number of bytes to advance from the end of one line
+ to the beginning of the next line. */
+- rowskip = (dst->mode_info->pitch - dst->mode_info->bytes_per_pixel * width);
++ if (grub_mul (dst->mode_info->bytes_per_pixel, width, ) ||
++ grub_sub (dst->mode_info->pitch, rowskip, ))
++return;
+
+ /* Get the start address. */
+ dstptr = grub_video_fb_get_video_ptr (dst, x, y);
+@@ -161,7 +168,9 @@ grub_video_fbfill_direct8 (struct grub_video_fbblit_info
*dst,
+
+ /* Calculate the number of bytes to advance from the end of one line
+ to the beginning of the next line. */
+- rowskip = dst->mode_info->pitch - dst->mode_info->bytes_per_pixel * width;
++ if (grub_mul (dst->mode_info->bytes_per_pixel, width, ) ||
++ grub_sub (dst->mode_info->pitch, rowskip, ))
++return;
+
+ /* Get the start address. */
+ dstptr = grub_video_fb_get_video_ptr (dst, x, y);
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 24a269d90d..710ab5e361 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -78,6 +78,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0029-normal-completion-Fix-leaking-of-memory-when-process.patch \
file://0030-commands-hashsum-Fix-a-memory-leak.patch \
file://0031-video-efi_gop-Remove-unnecessary-return-value-of-gru.patch \
+ file://0032-video-fb-fbfill-Fix-potential-integer-overflow.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161920):
https://lists.openembedded.org/g/openembedded-core/message/161920
Mute This Topic:
[OE-core] [PATCH 30/46][dunfell] grub: fix a memory leak
Add a fix of a memory leak in grub's commands/hashsum. It is a part
of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...0-commands-hashsum-Fix-a-memory-leak.patch | 56 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 57 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0030-commands-hashsum-Fix-a-memory-leak.patch
diff --git
a/meta/recipes-bsp/grub/files/0030-commands-hashsum-Fix-a-memory-leak.patch
b/meta/recipes-bsp/grub/files/0030-commands-hashsum-Fix-a-memory-leak.patch
new file mode 100644
index 00..e34a19e12c
--- /dev/null
+++ b/meta/recipes-bsp/grub/files/0030-commands-hashsum-Fix-a-memory-leak.patch
@@ -0,0 +1,56 @@
+From b136fa14d26d1833ffcb852f86e65da5960cfb99 Mon Sep 17 00:00:00 2001
+From: Chris Coulson
+Date: Tue, 1 Dec 2020 23:41:24 +
+Subject: [PATCH] commands/hashsum: Fix a memory leak
+
+check_list() uses grub_file_getline(), which allocates a buffer.
+If the hash list file contains invalid lines, the function leaks
+this buffer when it returns an error.
+
+Fixes: CID 176635
+
+Signed-off-by: Chris Coulson
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=8b6f528e52e18b7a69f90b8dc3671d7b1147d9f3]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/commands/hashsum.c | 15 ---
+ 1 file changed, 12 insertions(+), 3 deletions(-)
+
+diff --git a/grub-core/commands/hashsum.c b/grub-core/commands/hashsum.c
+index 456ba90..b8a22b0 100644
+--- a/grub-core/commands/hashsum.c
b/grub-core/commands/hashsum.c
+@@ -128,11 +128,17 @@ check_list (const gcry_md_spec_t *hash, const char
*hashfilename,
+ high = hextoval (*p++);
+ low = hextoval (*p++);
+ if (high < 0 || low < 0)
+- return grub_error (GRUB_ERR_BAD_FILE_TYPE, "invalid hash list");
++ {
++grub_free (buf);
++return grub_error (GRUB_ERR_BAD_FILE_TYPE, "invalid hash list");
++ }
+ expected[i] = (high << 4) | low;
+ }
+ if ((p[0] != ' ' && p[0] != '\t') || (p[1] != ' ' && p[1] != '\t'))
+- return grub_error (GRUB_ERR_BAD_FILE_TYPE, "invalid hash list");
++ {
++grub_free (buf);
++return grub_error (GRUB_ERR_BAD_FILE_TYPE, "invalid hash list");
++ }
+ p += 2;
+ if (prefix)
+ {
+@@ -140,7 +146,10 @@ check_list (const gcry_md_spec_t *hash, const char
*hashfilename,
+
+ filename = grub_xasprintf ("%s/%s", prefix, p);
+ if (!filename)
+- return grub_errno;
++ {
++grub_free (buf);
++return grub_errno;
++ }
+ file = grub_file_open (filename, GRUB_FILE_TYPE_TO_HASH
+| (!uncompress ? GRUB_FILE_TYPE_NO_DECOMPRESS
+ : GRUB_FILE_TYPE_NONE));
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 1460e559b9..d18e329b96 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -76,6 +76,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0027-libgcrypt-mpi-Fix-possible-NULL-dereference.patch \
file://0028-syslinux-Fix-memory-leak-while-parsing.patch \
file://0029-normal-completion-Fix-leaking-of-memory-when-process.patch \
+ file://0030-commands-hashsum-Fix-a-memory-leak.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161918):
https://lists.openembedded.org/g/openembedded-core/message/161918
Mute This Topic: https://lists.openembedded.org/mt/89229706/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 41/46][dunfell] grub: add a fix for NULL pointer dereference
This patch adds a fix for a NULL pointer dereference in grub's
util/grub-install. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...nstall-Fix-NULL-pointer-dereferences.patch | 41 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 42 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0041-util-grub-install-Fix-NULL-pointer-dereferences.patch
diff --git
a/meta/recipes-bsp/grub/files/0041-util-grub-install-Fix-NULL-pointer-dereferences.patch
b/meta/recipes-bsp/grub/files/0041-util-grub-install-Fix-NULL-pointer-dereferences.patch
new file mode 100644
index 00..ea563a41a0
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0041-util-grub-install-Fix-NULL-pointer-dereferences.patch
@@ -0,0 +1,41 @@
+From 5d2dd0052474a882a22e47cc8c3ed87a01819f6b Mon Sep 17 00:00:00 2001
+From: Daniel Kiper
+Date: Thu, 25 Feb 2021 18:35:01 +0100
+Subject: [PATCH] util/grub-install: Fix NULL pointer dereferences
+
+Two grub_device_open() calls does not have associated NULL checks
+for returned values. Fix that and appease the Coverity.
+
+Fixes: CID 314583
+
+Signed-off-by: Daniel Kiper
+Reviewed-by: Javier Martinez Canillas
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=8b3a95655b4391122e7b0315d8cc6f876caf8183]
+Signed-off-by: Marta Rybczynska
+---
+ util/grub-install.c | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/util/grub-install.c b/util/grub-install.c
+index a82725f..367350f 100644
+--- a/util/grub-install.c
b/util/grub-install.c
+@@ -1775,6 +1775,8 @@ main (int argc, char *argv[])
+ fill_core_services (core_services);
+
+ ins_dev = grub_device_open (install_drive);
++if (ins_dev == NULL)
++ grub_util_error ("%s", grub_errmsg);
+
+ bless (ins_dev, core_services, 0);
+
+@@ -1875,6 +1877,8 @@ main (int argc, char *argv[])
+ fill_core_services(core_services);
+
+ ins_dev = grub_device_open (install_drive);
++if (ins_dev == NULL)
++ grub_util_error ("%s", grub_errmsg);
+
+ bless (ins_dev, boot_efi, 1);
+ if (!removable && update_nvram)
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index fad7415e0d..7ca0b469e9 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -87,6 +87,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0038-loader-xnu-Fix-memory-leak.patch \
file://0039-loader-xnu-Free-driverkey-data-when-an-error-is-dete.patch \
file://0040-loader-xnu-Check-if-pointer-is-NULL-before-using-it.patch \
+ file://0041-util-grub-install-Fix-NULL-pointer-dereferences.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161929):
https://lists.openembedded.org/g/openembedded-core/message/161929
Mute This Topic: https://lists.openembedded.org/mt/89229717/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 43/46][dunfell] grub: fix incorrect use of a negative value
This patch adds a fix for an incorrect use of a negative value in grub's
util/glue-efi. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...x-incorrect-use-of-a-possibly-negati.patch | 50 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 51 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0043-util-glue-efi-Fix-incorrect-use-of-a-possibly-negati.patch
diff --git
a/meta/recipes-bsp/grub/files/0043-util-glue-efi-Fix-incorrect-use-of-a-possibly-negati.patch
b/meta/recipes-bsp/grub/files/0043-util-glue-efi-Fix-incorrect-use-of-a-possibly-negati.patch
new file mode 100644
index 00..66d7c0aa42
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0043-util-glue-efi-Fix-incorrect-use-of-a-possibly-negati.patch
@@ -0,0 +1,50 @@
+From e301a0f38a2130eb80f346c31e43bf5089af583c Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Fri, 4 Dec 2020 15:04:28 +
+Subject: [PATCH] util/glue-efi: Fix incorrect use of a possibly negative value
+
+It is possible for the ftell() function to return a negative value,
+although it is fairly unlikely here, we should be checking for
+a negative value before we assign it to an unsigned value.
+
+Fixes: CID 73744
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=1641d74e16f9d1ca35ba1a87ee4a0bf3afa48e72]
+Signed-off-by: Marta Rybczynska
+---
+ util/glue-efi.c | 14 --
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/util/glue-efi.c b/util/glue-efi.c
+index 68f5316..de0fa6d 100644
+--- a/util/glue-efi.c
b/util/glue-efi.c
+@@ -39,13 +39,23 @@ write_fat (FILE *in32, FILE *in64, FILE *out, const char
*out_filename,
+ struct grub_macho_fat_header head;
+ struct grub_macho_fat_arch arch32, arch64;
+ grub_uint32_t size32, size64;
++ long size;
+ char *buf;
+
+ fseek (in32, 0, SEEK_END);
+- size32 = ftell (in32);
++ size = ftell (in32);
++ if (size < 0)
++grub_util_error ("cannot get end of input file '%s': %s",
++ name32, strerror (errno));
++ size32 = (grub_uint32_t) size;
+ fseek (in32, 0, SEEK_SET);
++
+ fseek (in64, 0, SEEK_END);
+- size64 = ftell (in64);
++ size = ftell (in64);
++ if (size < 0)
++grub_util_error ("cannot get end of input file '%s': %s",
++ name64, strerror (errno));
++ size64 = (grub_uint64_t) size;
+ fseek (in64, 0, SEEK_SET);
+
+ head.magic = grub_cpu_to_le32_compile_time (GRUB_MACHO_FAT_EFI_MAGIC);
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index a1fbc5e644..2f230065b2 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -89,6 +89,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0040-loader-xnu-Check-if-pointer-is-NULL-before-using-it.patch \
file://0041-util-grub-install-Fix-NULL-pointer-dereferences.patch \
file://0042-util-grub-editenv-Fix-incorrect-casting-of-a-signed-.patch \
+
file://0043-util-glue-efi-Fix-incorrect-use-of-a-possibly-negati.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161931):
https://lists.openembedded.org/g/openembedded-core/message/161931
Mute This Topic: https://lists.openembedded.org/mt/89229720/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 42/46][dunfell] grub: add a fix for an incorrect cast
This patch adds a fix for incorrect casting from signed to unsigned
in grub's util/grub-editenv. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...v-Fix-incorrect-casting-of-a-signed-.patch | 46 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 47 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0042-util-grub-editenv-Fix-incorrect-casting-of-a-signed-.patch
diff --git
a/meta/recipes-bsp/grub/files/0042-util-grub-editenv-Fix-incorrect-casting-of-a-signed-.patch
b/meta/recipes-bsp/grub/files/0042-util-grub-editenv-Fix-incorrect-casting-of-a-signed-.patch
new file mode 100644
index 00..0cd8ec3611
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0042-util-grub-editenv-Fix-incorrect-casting-of-a-signed-.patch
@@ -0,0 +1,46 @@
+From 3d68daf2567aace4b52bd238cfd4a8111af3bc04 Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Thu, 5 Nov 2020 14:33:50 +
+Subject: [PATCH] util/grub-editenv: Fix incorrect casting of a signed value
+
+The return value of ftell() may be negative (-1) on error. While it is
+probably unlikely to occur, we should not blindly cast to an unsigned
+value without first testing that it is not negative.
+
+Fixes: CID 73856
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=5dc41edc4eba259c6043ae7698c245ec1baaacc6]
+Signed-off-by: Marta Rybczynska
+---
+ util/grub-editenv.c | 8 +++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/util/grub-editenv.c b/util/grub-editenv.c
+index f3662c9..db6f187 100644
+--- a/util/grub-editenv.c
b/util/grub-editenv.c
+@@ -125,6 +125,7 @@ open_envblk_file (const char *name)
+ {
+ FILE *fp;
+ char *buf;
++ long loc;
+ size_t size;
+ grub_envblk_t envblk;
+
+@@ -143,7 +144,12 @@ open_envblk_file (const char *name)
+ grub_util_error (_("cannot seek `%s': %s"), name,
+strerror (errno));
+
+- size = (size_t) ftell (fp);
++ loc = ftell (fp);
++ if (loc < 0)
++grub_util_error (_("cannot get file location `%s': %s"), name,
++ strerror (errno));
++
++ size = (size_t) loc;
+
+ if (fseek (fp, 0, SEEK_SET) < 0)
+ grub_util_error (_("cannot seek `%s': %s"), name,
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 7ca0b469e9..a1fbc5e644 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -88,6 +88,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0039-loader-xnu-Free-driverkey-data-when-an-error-is-dete.patch \
file://0040-loader-xnu-Check-if-pointer-is-NULL-before-using-it.patch \
file://0041-util-grub-install-Fix-NULL-pointer-dereferences.patch \
+
file://0042-util-grub-editenv-Fix-incorrect-casting-of-a-signed-.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161930):
https://lists.openembedded.org/g/openembedded-core/message/161930
Mute This Topic: https://lists.openembedded.org/mt/89229719/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 40/46][dunfell] grub: add a check for a NULL pointer
This patch adds a check for a NULL pointer before use in grub's
loader/xnu. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...k-if-pointer-is-NULL-before-using-it.patch | 42 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 43 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0040-loader-xnu-Check-if-pointer-is-NULL-before-using-it.patch
diff --git
a/meta/recipes-bsp/grub/files/0040-loader-xnu-Check-if-pointer-is-NULL-before-using-it.patch
b/meta/recipes-bsp/grub/files/0040-loader-xnu-Check-if-pointer-is-NULL-before-using-it.patch
new file mode 100644
index 00..8081f7763a
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0040-loader-xnu-Check-if-pointer-is-NULL-before-using-it.patch
@@ -0,0 +1,42 @@
+From 778a3fffd19229e5650a1abfb06c974949991cd4 Mon Sep 17 00:00:00 2001
+From: Paulo Flabiano Smorigo
+Date: Mon, 30 Nov 2020 10:36:00 -0300
+Subject: [PATCH] loader/xnu: Check if pointer is NULL before using it
+
+Fixes: CID 73654
+
+Signed-off-by: Paulo Flabiano Smorigo
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=7c8a2b5d1421a0f2a33d33531f7561f3da93b844]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/loader/xnu.c | 8
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/grub-core/loader/xnu.c b/grub-core/loader/xnu.c
+index 39ceff8..adc048c 100644
+--- a/grub-core/loader/xnu.c
b/grub-core/loader/xnu.c
+@@ -667,6 +667,9 @@ grub_xnu_load_driver (char *infoplistname, grub_file_t
binaryfile,
+ char *name, *nameend;
+ int namelen;
+
++ if (infoplistname == NULL)
++return grub_error (GRUB_ERR_BAD_FILENAME, N_("missing p-list filename"));
++
+ name = get_name_ptr (infoplistname);
+ nameend = grub_strchr (name, '/');
+
+@@ -698,10 +701,7 @@ grub_xnu_load_driver (char *infoplistname, grub_file_t
binaryfile,
+ else
+ macho = 0;
+
+- if (infoplistname)
+-infoplist = grub_file_open (infoplistname, GRUB_FILE_TYPE_XNU_INFO_PLIST);
+- else
+-infoplist = 0;
++ infoplist = grub_file_open (infoplistname, GRUB_FILE_TYPE_XNU_INFO_PLIST);
+ grub_errno = GRUB_ERR_NONE;
+ if (infoplist)
+ {
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index eebe9a7233..fad7415e0d 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -86,6 +86,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0037-loader-bsd-Check-for-NULL-arg-up-front.patch \
file://0038-loader-xnu-Fix-memory-leak.patch \
file://0039-loader-xnu-Free-driverkey-data-when-an-error-is-dete.patch \
+
file://0040-loader-xnu-Check-if-pointer-is-NULL-before-using-it.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161928):
https://lists.openembedded.org/g/openembedded-core/message/161928
Mute This Topic: https://lists.openembedded.org/mt/89229716/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 39/46][dunfell] grub: avoid a memory leak
This patch fixes a memory leak in grub's loader/xnu when an error is
detected in grub_xnu_writetree_toheap(). It is a part of a security
series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...driverkey-data-when-an-error-is-dete.patch | 77 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 78 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0039-loader-xnu-Free-driverkey-data-when-an-error-is-dete.patch
diff --git
a/meta/recipes-bsp/grub/files/0039-loader-xnu-Free-driverkey-data-when-an-error-is-dete.patch
b/meta/recipes-bsp/grub/files/0039-loader-xnu-Free-driverkey-data-when-an-error-is-dete.patch
new file mode 100644
index 00..f9ad0fc34c
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0039-loader-xnu-Free-driverkey-data-when-an-error-is-dete.patch
@@ -0,0 +1,77 @@
+From 81117a77a9e945ee5e7c1f12bd5667e2a16cbe32 Mon Sep 17 00:00:00 2001
+From: Marco A Benatto
+Date: Mon, 30 Nov 2020 12:18:24 -0300
+Subject: [PATCH] loader/xnu: Free driverkey data when an error is detected in
+ grub_xnu_writetree_toheap()
+
+... to avoid memory leaks.
+
+Fixes: CID 96640
+
+Signed-off-by: Marco A Benatto
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=4b4027b6b1c877d7ab467896b04c7bd1aadcfa15]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/loader/xnu.c | 24
+ 1 file changed, 20 insertions(+), 4 deletions(-)
+
+diff --git a/grub-core/loader/xnu.c b/grub-core/loader/xnu.c
+index b3029a8..39ceff8 100644
+--- a/grub-core/loader/xnu.c
b/grub-core/loader/xnu.c
+@@ -224,26 +224,33 @@ grub_xnu_writetree_toheap (grub_addr_t *target,
grub_size_t *size)
+ if (! memorymap)
+ return grub_errno;
+
+- driverkey = (struct grub_xnu_devtree_key *) grub_malloc (sizeof
(*driverkey));
++ driverkey = (struct grub_xnu_devtree_key *) grub_zalloc (sizeof
(*driverkey));
+ if (! driverkey)
+ return grub_errno;
+ driverkey->name = grub_strdup ("DeviceTree");
+ if (! driverkey->name)
+-return grub_errno;
++{
++ err = grub_errno;
++ goto fail;
++}
++
+ driverkey->datasize = sizeof (*extdesc);
+ driverkey->next = memorymap->first_child;
+ memorymap->first_child = driverkey;
+ driverkey->data = extdesc
+ = (struct grub_xnu_extdesc *) grub_malloc (sizeof (*extdesc));
+ if (! driverkey->data)
+-return grub_errno;
++{
++ err = grub_errno;
++ goto fail;
++}
+
+ /* Allocate the space based on the size with dummy value. */
+ *size = grub_xnu_writetree_get_size (grub_xnu_devtree_root, "/");
+ err = grub_xnu_heap_malloc (ALIGN_UP (*size + 1, GRUB_XNU_PAGESIZE),
+ , target);
+ if (err)
+-return err;
++goto fail;
+
+ /* Put real data in the dummy. */
+ extdesc->addr = *target;
+@@ -252,6 +259,15 @@ grub_xnu_writetree_toheap (grub_addr_t *target,
grub_size_t *size)
+ /* Write the tree to heap. */
+ grub_xnu_writetree_toheap_real (src, grub_xnu_devtree_root, "/");
+ return GRUB_ERR_NONE;
++
++ fail:
++ memorymap->first_child = NULL;
++
++ grub_free (driverkey->data);
++ grub_free (driverkey->name);
++ grub_free (driverkey);
++
++ return err;
+ }
+
+ /* Find a key or value in parent key. */
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index c9e7a06a3f..eebe9a7233 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -85,6 +85,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0036-gfxmenu-gui_list-Remove-code-that-coverity-is-flaggi.patch \
file://0037-loader-bsd-Check-for-NULL-arg-up-front.patch \
file://0038-loader-xnu-Fix-memory-leak.patch \
+
file://0039-loader-xnu-Free-driverkey-data-when-an-error-is-dete.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161927):
https://lists.openembedded.org/g/openembedded-core/message/161927
Mute This Topic: https://lists.openembedded.org/mt/89229715/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 45/46][dunfell] grub: avoid a NULL pointer dereference
This patch adds a fix for a NULL pointer dereference in grub's
commands/ls. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...ire-device_name-is-not-NULL-before-p.patch | 33 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 34 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0045-commands-ls-Require-device_name-is-not-NULL-before-p.patch
diff --git
a/meta/recipes-bsp/grub/files/0045-commands-ls-Require-device_name-is-not-NULL-before-p.patch
b/meta/recipes-bsp/grub/files/0045-commands-ls-Require-device_name-is-not-NULL-before-p.patch
new file mode 100644
index 00..5a327fe1d2
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0045-commands-ls-Require-device_name-is-not-NULL-before-p.patch
@@ -0,0 +1,33 @@
+From dd82f98fa642907817f59aeaf3761b786898df85 Mon Sep 17 00:00:00 2001
+From: Daniel Axtens
+Date: Mon, 11 Jan 2021 16:57:37 +1100
+Subject: [PATCH] commands/ls: Require device_name is not NULL before printing
+
+This can be triggered with:
+ ls -l (0 0*)
+and causes a NULL deref in grub_normal_print_device_info().
+
+I'm not sure if there's any implication with the IEEE 1275 platform.
+
+Signed-off-by: Daniel Axtens
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=6afbe6063c95b827372f9ec310c9fc7461311eb1]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/commands/ls.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/grub-core/commands/ls.c b/grub-core/commands/ls.c
+index 5b7491a..326d2d6 100644
+--- a/grub-core/commands/ls.c
b/grub-core/commands/ls.c
+@@ -196,7 +196,7 @@ grub_ls_list_files (char *dirname, int longlist, int all,
int human)
+ goto fail;
+ }
+
+- if (! *path)
++ if (! *path && device_name)
+ {
+ if (grub_errno == GRUB_ERR_UNKNOWN_FS)
+ grub_errno = GRUB_ERR_NONE;
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 84b8b8d1be..0454b09d52 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -91,6 +91,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0042-util-grub-editenv-Fix-incorrect-casting-of-a-signed-.patch \
file://0043-util-glue-efi-Fix-incorrect-use-of-a-possibly-negati.patch \
file://0044-script-execute-Fix-NULL-dereference-in-grub_script_e.patch \
+
file://0045-commands-ls-Require-device_name-is-not-NULL-before-p.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161933):
https://lists.openembedded.org/g/openembedded-core/message/161933
Mute This Topic: https://lists.openembedded.org/mt/89229722/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 34/46][dunfell] grub: fix a possible integer overflow
This patch adds a fix for a possible integer overflow in grub's
video/fb/video_fb. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...deo_fb-Fix-possible-integer-overflow.patch | 39 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 40 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0034-video-fb-video_fb-Fix-possible-integer-overflow.patch
diff --git
a/meta/recipes-bsp/grub/files/0034-video-fb-video_fb-Fix-possible-integer-overflow.patch
b/meta/recipes-bsp/grub/files/0034-video-fb-video_fb-Fix-possible-integer-overflow.patch
new file mode 100644
index 00..c82b2c7df0
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0034-video-fb-video_fb-Fix-possible-integer-overflow.patch
@@ -0,0 +1,39 @@
+From aac5574ff340a665ccc78d4c3d61596ac67acbbe Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Fri, 4 Dec 2020 14:51:30 +
+Subject: [PATCH] video/fb/video_fb: Fix possible integer overflow
+
+It is minimal possibility that the values being used here will overflow.
+So, change the code to use the safemath function grub_mul() to ensure
+that doesn't happen.
+
+Fixes: CID 73761
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=08413f2f4edec0e2d9bf15f836f6ee5ca2e379cb]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/video/fb/video_fb.c | 8 +++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/grub-core/video/fb/video_fb.c b/grub-core/video/fb/video_fb.c
+index 1c9a138..ae6b89f 100644
+--- a/grub-core/video/fb/video_fb.c
b/grub-core/video/fb/video_fb.c
+@@ -1537,7 +1537,13 @@ doublebuf_pageflipping_init (struct
grub_video_mode_info *mode_info,
+volatile void *page1_ptr)
+ {
+ grub_err_t err;
+- grub_size_t page_size = mode_info->pitch * mode_info->height;
++ grub_size_t page_size = 0;
++
++ if (grub_mul (mode_info->pitch, mode_info->height, _size))
++{
++ /* Shouldn't happen, but if it does we've a bug. */
++ return GRUB_ERR_BUG;
++}
+
+ framebuffer.offscreen_buffer = grub_malloc (page_size);
+ if (! framebuffer.offscreen_buffer)
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 8b5b9e3b3e..04c9b4c092 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -80,6 +80,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0031-video-efi_gop-Remove-unnecessary-return-value-of-gru.patch \
file://0032-video-fb-fbfill-Fix-potential-integer-overflow.patch \
file://0033-video-fb-video_fb-Fix-multiple-integer-overflows.patch \
+ file://0034-video-fb-video_fb-Fix-possible-integer-overflow.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161922):
https://lists.openembedded.org/g/openembedded-core/message/161922
Mute This Topic: https://lists.openembedded.org/mt/89229710/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 33/46][dunfell] grub: fix multiple integer overflows
This patch adds a fix for multiple integer overflows in grub's
video/fb/video_fb. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...eo_fb-Fix-multiple-integer-overflows.patch | 104 ++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 105 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0033-video-fb-video_fb-Fix-multiple-integer-overflows.patch
diff --git
a/meta/recipes-bsp/grub/files/0033-video-fb-video_fb-Fix-multiple-integer-overflows.patch
b/meta/recipes-bsp/grub/files/0033-video-fb-video_fb-Fix-multiple-integer-overflows.patch
new file mode 100644
index 00..544e7f31ae
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0033-video-fb-video_fb-Fix-multiple-integer-overflows.patch
@@ -0,0 +1,104 @@
+From 69b91f7466a5ad5fb85039a5b4118efb77ad6347 Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Wed, 4 Nov 2020 14:43:44 +
+Subject: [PATCH] video/fb/video_fb: Fix multiple integer overflows
+
+The calculation of the unsigned 64-bit value is being generated by
+multiplying 2, signed or unsigned, 32-bit integers which may overflow
+before promotion to unsigned 64-bit. Fix all of them.
+
+Fixes: CID 73703, CID 73767, CID 73833
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=08e098b1dbf01e96376f594b337491bc4cfa48dd]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/video/fb/video_fb.c | 52 ---
+ 1 file changed, 36 insertions(+), 16 deletions(-)
+
+diff --git a/grub-core/video/fb/video_fb.c b/grub-core/video/fb/video_fb.c
+index 1a602c8..1c9a138 100644
+--- a/grub-core/video/fb/video_fb.c
b/grub-core/video/fb/video_fb.c
+@@ -25,6 +25,7 @@
+ #include
+ #include
+ #include
++#include
+
+ GRUB_MOD_LICENSE ("GPLv3+");
+
+@@ -1417,15 +1418,23 @@ doublebuf_blit_update_screen (void)
+ {
+ if (framebuffer.current_dirty.first_line
+ <= framebuffer.current_dirty.last_line)
+-grub_memcpy ((char *) framebuffer.pages[0]
+- + framebuffer.current_dirty.first_line
+- * framebuffer.back_target->mode_info.pitch,
+- (char *) framebuffer.back_target->data
+- + framebuffer.current_dirty.first_line
+- * framebuffer.back_target->mode_info.pitch,
+- framebuffer.back_target->mode_info.pitch
+- * (framebuffer.current_dirty.last_line
+- - framebuffer.current_dirty.first_line));
++{
++ grub_size_t copy_size;
++
++ if (grub_sub (framebuffer.current_dirty.last_line,
++ framebuffer.current_dirty.first_line, _size) ||
++grub_mul (framebuffer.back_target->mode_info.pitch, copy_size,
_size))
++ {
++/* Shouldn't happen, but if it does we've a bug. */
++return GRUB_ERR_BUG;
++ }
++
++ grub_memcpy ((char *) framebuffer.pages[0] +
framebuffer.current_dirty.first_line *
++ framebuffer.back_target->mode_info.pitch,
++ (char *) framebuffer.back_target->data +
framebuffer.current_dirty.first_line *
++ framebuffer.back_target->mode_info.pitch,
++ copy_size);
++}
+ framebuffer.current_dirty.first_line
+ = framebuffer.back_target->mode_info.height;
+ framebuffer.current_dirty.last_line = 0;
+@@ -1439,7 +1448,7 @@ grub_video_fb_doublebuf_blit_init (struct
grub_video_fbrender_target **back,
+ volatile void *framebuf)
+ {
+ grub_err_t err;
+- grub_size_t page_size = mode_info.pitch * mode_info.height;
++ grub_size_t page_size = (grub_size_t) mode_info.pitch * mode_info.height;
+
+ framebuffer.offscreen_buffer = grub_zalloc (page_size);
+ if (! framebuffer.offscreen_buffer)
+@@ -1482,12 +1491,23 @@ doublebuf_pageflipping_update_screen (void)
+ last_line = framebuffer.previous_dirty.last_line;
+
+ if (first_line <= last_line)
+-grub_memcpy ((char *) framebuffer.pages[framebuffer.render_page]
+- + first_line * framebuffer.back_target->mode_info.pitch,
+- (char *) framebuffer.back_target->data
+- + first_line * framebuffer.back_target->mode_info.pitch,
+- framebuffer.back_target->mode_info.pitch
+- * (last_line - first_line));
++{
++ grub_size_t copy_size;
++
++ if (grub_sub (last_line, first_line, _size) ||
++grub_mul (framebuffer.back_target->mode_info.pitch, copy_size,
_size))
++ {
++/* Shouldn't happen, but if it does we've a bug. */
++return GRUB_ERR_BUG;
++ }
++
++ grub_memcpy ((char *) framebuffer.pages[framebuffer.render_page] +
first_line *
++ framebuffer.back_target->mode_info.pitch,
++ (char *) framebuffer.back_target->data + first_line *
++
[OE-core] [PATCH 36/46][dunfell] grub: remove dead code
This patch removes dead code from grub's gfxmenu/gui_list. It is
a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...-Remove-code-that-coverity-is-flaggi.patch | 34 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 35 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0036-gfxmenu-gui_list-Remove-code-that-coverity-is-flaggi.patch
diff --git
a/meta/recipes-bsp/grub/files/0036-gfxmenu-gui_list-Remove-code-that-coverity-is-flaggi.patch
b/meta/recipes-bsp/grub/files/0036-gfxmenu-gui_list-Remove-code-that-coverity-is-flaggi.patch
new file mode 100644
index 00..61e5e5797d
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0036-gfxmenu-gui_list-Remove-code-that-coverity-is-flaggi.patch
@@ -0,0 +1,34 @@
+From 9433cb3a37c03f22c2fa769121f1f509fd031ae9 Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Mon, 7 Dec 2020 14:44:47 +
+Subject: [PATCH] gfxmenu/gui_list: Remove code that coverity is flagging as
+ dead
+
+The test of value for NULL before calling grub_strdup() is not required,
+since the if condition prior to this has already tested for value being
+NULL and cannot reach this code if it is.
+
+Fixes: CID 73659
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=4a1aa5917595650efbd46b581368c470ebee42ab]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/gfxmenu/gui_list.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/grub-core/gfxmenu/gui_list.c b/grub-core/gfxmenu/gui_list.c
+index 01477cd..df334a6 100644
+--- a/grub-core/gfxmenu/gui_list.c
b/grub-core/gfxmenu/gui_list.c
+@@ -771,7 +771,7 @@ list_set_property (void *vself, const char *name, const
char *value)
+ {
+ self->need_to_recreate_boxes = 1;
+ grub_free (self->selected_item_box_pattern);
+- self->selected_item_box_pattern = value ? grub_strdup (value) : 0;
++ self->selected_item_box_pattern = grub_strdup (value);
+ self->selected_item_box_pattern_inherit = 0;
+ }
+ }
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 75782b7eb2..1a4be33fca 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -82,6 +82,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0033-video-fb-video_fb-Fix-multiple-integer-overflows.patch \
file://0034-video-fb-video_fb-Fix-possible-integer-overflow.patch \
file://0035-video-readers-jpeg-Test-for-an-invalid-next-marker-r.patch \
+
file://0036-gfxmenu-gui_list-Remove-code-that-coverity-is-flaggi.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161924):
https://lists.openembedded.org/g/openembedded-core/message/161924
Mute This Topic: https://lists.openembedded.org/mt/89229712/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 35/46][dunfell] grub: test for malformed jpeg files
This patch adds a fix for handling malformed JPEG files in grub's
video/readers/jpeg. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...eg-Test-for-an-invalid-next-marker-r.patch | 38 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 39 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0035-video-readers-jpeg-Test-for-an-invalid-next-marker-r.patch
diff --git
a/meta/recipes-bsp/grub/files/0035-video-readers-jpeg-Test-for-an-invalid-next-marker-r.patch
b/meta/recipes-bsp/grub/files/0035-video-readers-jpeg-Test-for-an-invalid-next-marker-r.patch
new file mode 100644
index 00..3fca2aecb5
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0035-video-readers-jpeg-Test-for-an-invalid-next-marker-r.patch
@@ -0,0 +1,38 @@
+From 88361a7fd4e481a76e1159a63c9014fa997ef29c Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Fri, 4 Dec 2020 15:39:00 +
+Subject: [PATCH] video/readers/jpeg: Test for an invalid next marker reference
+ from a jpeg file
+
+While it may never happen, and potentially could be caught at the end of
+the function, it is worth checking up front for a bad reference to the
+next marker just in case of a maliciously crafted file being provided.
+
+Fixes: CID 73694
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=5f5eb7ca8e971227e95745abe541df3e1509360e]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/video/readers/jpeg.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/grub-core/video/readers/jpeg.c b/grub-core/video/readers/jpeg.c
+index 31359a4..0b6ce3c 100644
+--- a/grub-core/video/readers/jpeg.c
b/grub-core/video/readers/jpeg.c
+@@ -253,6 +253,12 @@ grub_jpeg_decode_quan_table (struct grub_jpeg_data *data)
+ next_marker = data->file->offset;
+ next_marker += grub_jpeg_get_word (data);
+
++ if (next_marker > data->file->size)
++{
++ /* Should never be set beyond the size of the file. */
++ return grub_error (GRUB_ERR_BAD_FILE_TYPE, "jpeg: invalid next
reference");
++}
++
+ while (data->file->offset + sizeof (data->quan_table[id]) + 1
+<= next_marker)
+ {
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 04c9b4c092..75782b7eb2 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -81,6 +81,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0032-video-fb-fbfill-Fix-potential-integer-overflow.patch \
file://0033-video-fb-video_fb-Fix-multiple-integer-overflows.patch \
file://0034-video-fb-video_fb-Fix-possible-integer-overflow.patch \
+
file://0035-video-readers-jpeg-Test-for-an-invalid-next-marker-r.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161923):
https://lists.openembedded.org/g/openembedded-core/message/161923
Mute This Topic: https://lists.openembedded.org/mt/89229711/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 38/46][dunfell] grub: add a fix for a memory leak
This patch adds a fix for a memory leak in grub's loader/xnu.
It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
.../0038-loader-xnu-Fix-memory-leak.patch | 38 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 39 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0038-loader-xnu-Fix-memory-leak.patch
diff --git a/meta/recipes-bsp/grub/files/0038-loader-xnu-Fix-memory-leak.patch
b/meta/recipes-bsp/grub/files/0038-loader-xnu-Fix-memory-leak.patch
new file mode 100644
index 00..41f09a22fc
--- /dev/null
+++ b/meta/recipes-bsp/grub/files/0038-loader-xnu-Fix-memory-leak.patch
@@ -0,0 +1,38 @@
+From 0a4aa7c16f65cdfaa1013f0796afa929f8d6dc1a Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Thu, 26 Nov 2020 12:53:10 +
+Subject: [PATCH] loader/xnu: Fix memory leak
+
+The code here is finished with the memory stored in name, but it only
+frees it if there curvalue is valid, while it could actually free it
+regardless.
+
+The fix is a simple relocation of the grub_free() to before the test
+of curvalue.
+
+Fixes: CID 96646
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=bcb59ece3263d118510c4440c4da0950f224bb7f]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/loader/xnu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/grub-core/loader/xnu.c b/grub-core/loader/xnu.c
+index 07232d2..b3029a8 100644
+--- a/grub-core/loader/xnu.c
b/grub-core/loader/xnu.c
+@@ -1388,9 +1388,9 @@ grub_xnu_fill_devicetree (void)
+ name[len] = 0;
+
+ curvalue = grub_xnu_create_value (curkey, name);
++grub_free (name);
+ if (!curvalue)
+ return grub_errno;
+-grub_free (name);
+
+ data = grub_malloc (grub_strlen (var->value) + 1);
+ if (!data)
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 8b55afccbb..c9e7a06a3f 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -84,6 +84,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0035-video-readers-jpeg-Test-for-an-invalid-next-marker-r.patch \
file://0036-gfxmenu-gui_list-Remove-code-that-coverity-is-flaggi.patch \
file://0037-loader-bsd-Check-for-NULL-arg-up-front.patch \
+ file://0038-loader-xnu-Fix-memory-leak.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161926):
https://lists.openembedded.org/g/openembedded-core/message/161926
Mute This Topic: https://lists.openembedded.org/mt/89229714/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 37/46][dunfell] grub: fix checking for NULL
This patch adds a fix for checking for NULL in grub's loader/bsd.
It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...ader-bsd-Check-for-NULL-arg-up-front.patch | 47 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 48 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0037-loader-bsd-Check-for-NULL-arg-up-front.patch
diff --git
a/meta/recipes-bsp/grub/files/0037-loader-bsd-Check-for-NULL-arg-up-front.patch
b/meta/recipes-bsp/grub/files/0037-loader-bsd-Check-for-NULL-arg-up-front.patch
new file mode 100644
index 00..34643e10ab
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0037-loader-bsd-Check-for-NULL-arg-up-front.patch
@@ -0,0 +1,47 @@
+From 7899384c8fdf9ed96566978c49b0c6e40e70703d Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Tue, 8 Dec 2020 21:47:13 +
+Subject: [PATCH] loader/bsd: Check for NULL arg up-front
+
+The code in the next block suggests that it is possible for .set to be
+true but .arg may still be NULL.
+
+This code assumes that it is never NULL, yet later is testing if it is
+NULL - that is inconsistent.
+
+So we should check first if .arg is not NULL, and remove this check that
+is being flagged by Coverity since it is no longer required.
+
+Fixes: CID 292471
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=5d5391b0a05abe76e04c1eb68dcc6cbef5326c4a]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/loader/i386/bsd.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/grub-core/loader/i386/bsd.c b/grub-core/loader/i386/bsd.c
+index b92cbe9..8432283 100644
+--- a/grub-core/loader/i386/bsd.c
b/grub-core/loader/i386/bsd.c
+@@ -1605,7 +1605,7 @@ grub_cmd_openbsd (grub_extcmd_context_t ctxt, int argc,
char *argv[])
+ kernel_type = KERNEL_TYPE_OPENBSD;
+ bootflags = grub_bsd_parse_flags (ctxt->state, openbsd_flags);
+
+- if (ctxt->state[OPENBSD_ROOT_ARG].set)
++ if (ctxt->state[OPENBSD_ROOT_ARG].set && ctxt->state[OPENBSD_ROOT_ARG].arg
!= NULL)
+ {
+ const char *arg = ctxt->state[OPENBSD_ROOT_ARG].arg;
+ unsigned type, unit, part;
+@@ -1622,7 +1622,7 @@ grub_cmd_openbsd (grub_extcmd_context_t ctxt, int argc,
char *argv[])
+ "unknown disk type name");
+
+ unit = grub_strtoul (arg, (char **) , 10);
+- if (! (arg && *arg >= 'a' && *arg <= 'z'))
++ if (! (*arg >= 'a' && *arg <= 'z'))
+ return grub_error (GRUB_ERR_BAD_ARGUMENT,
+ "only device specifications of form "
+ " are supported");
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 1a4be33fca..8b55afccbb 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -83,6 +83,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0034-video-fb-video_fb-Fix-possible-integer-overflow.patch \
file://0035-video-readers-jpeg-Test-for-an-invalid-next-marker-r.patch \
file://0036-gfxmenu-gui_list-Remove-code-that-coverity-is-flaggi.patch \
+ file://0037-loader-bsd-Check-for-NULL-arg-up-front.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161925):
https://lists.openembedded.org/g/openembedded-core/message/161925
Mute This Topic: https://lists.openembedded.org/mt/89229713/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 46/46][dunfell] grub: add a fix for a crash in scripts
This patch adds a fix for a crash in grub's script handling. It is
a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...void-crash-when-using-outside-a-func.patch | 37 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 38 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0046-script-execute-Avoid-crash-when-using-outside-a-func.patch
diff --git
a/meta/recipes-bsp/grub/files/0046-script-execute-Avoid-crash-when-using-outside-a-func.patch
b/meta/recipes-bsp/grub/files/0046-script-execute-Avoid-crash-when-using-outside-a-func.patch
new file mode 100644
index 00..84117a9073
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0046-script-execute-Avoid-crash-when-using-outside-a-func.patch
@@ -0,0 +1,37 @@
+From df2505c4c3cf42b0c419c99a5f9e1ce63e5a5938 Mon Sep 17 00:00:00 2001
+From: Daniel Axtens
+Date: Mon, 11 Jan 2021 17:30:42 +1100
+Subject: [PATCH] script/execute: Avoid crash when using "$#" outside a
+ function scope
+
+"$#" represents the number of arguments to a function. It is only
+defined in a function scope, where "scope" is non-NULL. Currently,
+if we attempt to evaluate "$#" outside a function scope, "scope" will
+be NULL and we will crash with a NULL pointer dereference.
+
+Do not attempt to count arguments for "$#" if "scope" is NULL. This
+will result in "$#" being interpreted as an empty string if evaluated
+outside a function scope.
+
+Signed-off-by: Daniel Axtens
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=fe0586347ee46f927ae27bb9673532da9f5dead5]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/script/execute.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/grub-core/script/execute.c b/grub-core/script/execute.c
+index 5ea2aef..23d34bd 100644
+--- a/grub-core/script/execute.c
b/grub-core/script/execute.c
+@@ -485,7 +485,7 @@ gettext_putvar (const char *str, grub_size_t len,
+ return 0;
+
+ /* Enough for any number. */
+- if (len == 1 && str[0] == '#')
++ if (len == 1 && str[0] == '#' && scope != NULL)
+ {
+ grub_snprintf (*ptr, 30, "%u", scope->argv.argc);
+ *ptr += grub_strlen (*ptr);
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 0454b09d52..75ef31f249 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -92,6 +92,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0043-util-glue-efi-Fix-incorrect-use-of-a-possibly-negati.patch \
file://0044-script-execute-Fix-NULL-dereference-in-grub_script_e.patch \
file://0045-commands-ls-Require-device_name-is-not-NULL-before-p.patch \
+
file://0046-script-execute-Avoid-crash-when-using-outside-a-func.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161934):
https://lists.openembedded.org/g/openembedded-core/message/161934
Mute This Topic: https://lists.openembedded.org/mt/89229723/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 44/46][dunfell] grub: add a fix for a NULL pointer dereference
This patch adds a fix for a NULL pointer dereference in grub's
script/execute. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...ix-NULL-dereference-in-grub_script_e.patch | 28 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 29 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0044-script-execute-Fix-NULL-dereference-in-grub_script_e.patch
diff --git
a/meta/recipes-bsp/grub/files/0044-script-execute-Fix-NULL-dereference-in-grub_script_e.patch
b/meta/recipes-bsp/grub/files/0044-script-execute-Fix-NULL-dereference-in-grub_script_e.patch
new file mode 100644
index 00..b279222fff
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0044-script-execute-Fix-NULL-dereference-in-grub_script_e.patch
@@ -0,0 +1,28 @@
+From f5fb56954e5926ced42a980c3e0842ffd5fea2aa Mon Sep 17 00:00:00 2001
+From: Daniel Axtens
+Date: Fri, 3 Apr 2020 23:05:13 +1100
+Subject: [PATCH] script/execute: Fix NULL dereference in
+ grub_script_execute_cmdline()
+
+Signed-off-by: Daniel Axtens
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=41ae93b2e6c75453514629bcfe684300e3aec0ce]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/script/execute.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/grub-core/script/execute.c b/grub-core/script/execute.c
+index 7e028e1..5ea2aef 100644
+--- a/grub-core/script/execute.c
b/grub-core/script/execute.c
+@@ -940,7 +940,7 @@ grub_script_execute_cmdline (struct grub_script_cmd *cmd)
+ struct grub_script_argv argv = { 0, 0, 0 };
+
+ /* Lookup the command. */
+- if (grub_script_arglist_to_argv (cmdline->arglist, ) || ! argv.args[0])
++ if (grub_script_arglist_to_argv (cmdline->arglist, ) || ! argv.args ||
! argv.args[0])
+ return grub_errno;
+
+ for (i = 0; i < argv.argc; i++)
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 2f230065b2..84b8b8d1be 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -90,6 +90,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0041-util-grub-install-Fix-NULL-pointer-dereferences.patch \
file://0042-util-grub-editenv-Fix-incorrect-casting-of-a-signed-.patch \
file://0043-util-glue-efi-Fix-incorrect-use-of-a-possibly-negati.patch \
+
file://0044-script-execute-Fix-NULL-dereference-in-grub_script_e.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161932):
https://lists.openembedded.org/g/openembedded-core/message/161932
Mute This Topic: https://lists.openembedded.org/mt/89229721/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 19/46][dunfell] grub: fix an integer overflow
This patch fixes a potential overflow in grub's disk/cryptodisk. It is
a part of a security series [1]
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...odisk-Fix-potential-integer-overflow.patch | 50 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 51 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0019-disk-cryptodisk-Fix-potential-integer-overflow.patch
diff --git
a/meta/recipes-bsp/grub/files/0019-disk-cryptodisk-Fix-potential-integer-overflow.patch
b/meta/recipes-bsp/grub/files/0019-disk-cryptodisk-Fix-potential-integer-overflow.patch
new file mode 100644
index 00..dd7fda357d
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0019-disk-cryptodisk-Fix-potential-integer-overflow.patch
@@ -0,0 +1,50 @@
+From 2550aaa0c23fdf8b6c54e00c6b838f2e3aa81fe2 Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Thu, 21 Jan 2021 11:38:31 +
+Subject: [PATCH] disk/cryptodisk: Fix potential integer overflow
+
+The encrypt and decrypt functions expect a grub_size_t. So, we need to
+ensure that the constant bit shift is using grub_size_t rather than
+unsigned int when it is performing the shift.
+
+Fixes: CID 307788
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=a201ad17caa430aa710654fdf2e6ab4c8166f031]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/disk/cryptodisk.c | 8
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/grub-core/disk/cryptodisk.c b/grub-core/disk/cryptodisk.c
+index 5037768..6883f48 100644
+--- a/grub-core/disk/cryptodisk.c
b/grub-core/disk/cryptodisk.c
+@@ -311,10 +311,10 @@ grub_cryptodisk_endecrypt (struct grub_cryptodisk *dev,
+ case GRUB_CRYPTODISK_MODE_CBC:
+ if (do_encrypt)
+ err = grub_crypto_cbc_encrypt (dev->cipher, data + i, data + i,
+- (1U << dev->log_sector_size), iv);
++ ((grub_size_t) 1 <<
dev->log_sector_size), iv);
+ else
+ err = grub_crypto_cbc_decrypt (dev->cipher, data + i, data + i,
+- (1U << dev->log_sector_size), iv);
++ ((grub_size_t) 1 <<
dev->log_sector_size), iv);
+ if (err)
+ return err;
+ break;
+@@ -322,10 +322,10 @@ grub_cryptodisk_endecrypt (struct grub_cryptodisk *dev,
+ case GRUB_CRYPTODISK_MODE_PCBC:
+ if (do_encrypt)
+ err = grub_crypto_pcbc_encrypt (dev->cipher, data + i, data + i,
+- (1U << dev->log_sector_size), iv);
++ ((grub_size_t) 1 <<
dev->log_sector_size), iv);
+ else
+ err = grub_crypto_pcbc_decrypt (dev->cipher, data + i, data + i,
+- (1U << dev->log_sector_size), iv);
++ ((grub_size_t) 1 <<
dev->log_sector_size), iv);
+ if (err)
+ return err;
+ break;
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 2fccdc2d62..130f32551b 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -65,6 +65,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0016-disk-ldm-Make-sure-comp-data-is-freed-before-exiting.patch \
file://0017-disk-ldm-If-failed-then-free-vg-variable-too.patch \
file://0018-disk-ldm-Fix-memory-leak-on-uninserted-lv-references.patch \
+ file://0019-disk-cryptodisk-Fix-potential-integer-overflow.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161907):
https://lists.openembedded.org/g/openembedded-core/message/161907
Mute This Topic: https://lists.openembedded.org/mt/89229693/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 21/46][dunfell] grub: add a fix for a possible negative shift
This patch adds a fix for a possible negative shift in grub's zfs.
It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...ix-possible-negative-shift-operation.patch | 42 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 43 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0021-zfs-Fix-possible-negative-shift-operation.patch
diff --git
a/meta/recipes-bsp/grub/files/0021-zfs-Fix-possible-negative-shift-operation.patch
b/meta/recipes-bsp/grub/files/0021-zfs-Fix-possible-negative-shift-operation.patch
new file mode 100644
index 00..12418858f9
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0021-zfs-Fix-possible-negative-shift-operation.patch
@@ -0,0 +1,42 @@
+From c757779e5d09719666c3b155afd2421978a107bd Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Tue, 24 Nov 2020 16:41:49 +
+Subject: [PATCH] zfs: Fix possible negative shift operation
+
+While it is possible for the return value from zfs_log2() to be zero
+(0), it is quite unlikely, given that the previous assignment to blksz
+is shifted up by SPA_MINBLOCKSHIFT (9) before 9 is subtracted at the
+assignment to epbs.
+
+But, while unlikely during a normal operation, it may be that a carefully
+crafted ZFS filesystem could result in a zero (0) value to the
+dn_datalbkszsec field, which means that the shift left does nothing
+and assigns zero (0) to blksz, resulting in a negative epbs value.
+
+Fixes: CID 73608
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=a02091834d3e167320d8a262ff04b8e83c5e616d]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/fs/zfs/zfs.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/grub-core/fs/zfs/zfs.c b/grub-core/fs/zfs/zfs.c
+index 36d0373..0c42cba 100644
+--- a/grub-core/fs/zfs/zfs.c
b/grub-core/fs/zfs/zfs.c
+@@ -2667,6 +2667,11 @@ dnode_get (dnode_end_t * mdn, grub_uint64_t objnum,
grub_uint8_t type,
+ blksz = grub_zfs_to_cpu16 (mdn->dn.dn_datablkszsec,
+mdn->endian) << SPA_MINBLOCKSHIFT;
+ epbs = zfs_log2 (blksz) - DNODE_SHIFT;
++
++ /* While this should never happen, we should check that epbs is not
negative. */
++ if (epbs < 0)
++epbs = 0;
++
+ blkid = objnum >> epbs;
+ idx = objnum & ((1 << epbs) - 1);
+
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 3c5274fd96..360e86685b 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -67,6 +67,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0018-disk-ldm-Fix-memory-leak-on-uninserted-lv-references.patch \
file://0019-disk-cryptodisk-Fix-potential-integer-overflow.patch \
file://0020-hfsplus-Check-that-the-volume-name-length-is-valid.patch \
+ file://0021-zfs-Fix-possible-negative-shift-operation.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161909):
https://lists.openembedded.org/g/openembedded-core/message/161909
Mute This Topic: https://lists.openembedded.org/mt/89229695/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 20/46][dunfell] grub: add a fix for a length check
This patch adds a fix for a volume name length check in grub's
hfsplus. It is a part of a security series [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg7.html
Signed-off-by: Marta Rybczynska
---
...that-the-volume-name-length-is-valid.patch | 43 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 44 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0020-hfsplus-Check-that-the-volume-name-length-is-valid.patch
diff --git
a/meta/recipes-bsp/grub/files/0020-hfsplus-Check-that-the-volume-name-length-is-valid.patch
b/meta/recipes-bsp/grub/files/0020-hfsplus-Check-that-the-volume-name-length-is-valid.patch
new file mode 100644
index 00..eb459c547f
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0020-hfsplus-Check-that-the-volume-name-length-is-valid.patch
@@ -0,0 +1,43 @@
+From 7c1813eeec78892fa651046cc224ae4e80d0c94d Mon Sep 17 00:00:00 2001
+From: Darren Kenny
+Date: Fri, 23 Oct 2020 17:09:31 +
+Subject: [PATCH] hfsplus: Check that the volume name length is valid
+
+HFS+ documentation suggests that the maximum filename and volume name is
+255 Unicode characters in length.
+
+So, when converting from big-endian to little-endian, we should ensure
+that the name of the volume has a length that is between 0 and 255,
+inclusive.
+
+Fixes: CID 73641
+
+Signed-off-by: Darren Kenny
+Reviewed-by: Daniel Kiper
+
+Upstream-Status: Backport
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=2298f6e0d951251bb9ca97d891d1bc8b74515f8c]
+Signed-off-by: Marta Rybczynska
+---
+ grub-core/fs/hfsplus.c | 9 +
+ 1 file changed, 9 insertions(+)
+
+diff --git a/grub-core/fs/hfsplus.c b/grub-core/fs/hfsplus.c
+index dae43be..03c3c4c 100644
+--- a/grub-core/fs/hfsplus.c
b/grub-core/fs/hfsplus.c
+@@ -1007,6 +1007,15 @@ grub_hfsplus_label (grub_device_t device, char **label)
+ grub_hfsplus_btree_recptr (>catalog_tree, node, ptr);
+
+ label_len = grub_be_to_cpu16 (catkey->namelen);
++
++ /* Ensure that the length is >= 0. */
++ if (label_len < 0)
++label_len = 0;
++
++ /* Ensure label length is at most 255 Unicode characters. */
++ if (label_len > 255)
++label_len = 255;
++
+ label_name = grub_calloc (label_len, sizeof (*label_name));
+ if (!label_name)
+ {
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 130f32551b..3c5274fd96 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -66,6 +66,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0017-disk-ldm-If-failed-then-free-vg-variable-too.patch \
file://0018-disk-ldm-Fix-memory-leak-on-uninserted-lv-references.patch \
file://0019-disk-cryptodisk-Fix-potential-integer-overflow.patch \
+
file://0020-hfsplus-Check-that-the-volume-name-length-is-valid.patch \
"
SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
SRC_URI[sha256sum] =
"f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161908):
https://lists.openembedded.org/g/openembedded-core/message/161908
Mute This Topic: https://lists.openembedded.org/mt/89229694/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [Openembedded-architecture] Kirkstone Layer Compatibility
The [3] should be https://git.openembedded.org/openembedded-core/commit/?id=311e61ae14b7216f5b98f1afe0e791644a07c9d0 that's where LAYERSERIES_CORENAMES was changed to kirkstone (it's not due to LAYERSERIES_COMPAT changes, these changes are what people need to update in their layer). On Fri, Feb 18, 2022 at 7:57 AM Alejandro Hernandez Samaniego < alejan...@enedino.org> wrote: > Hello everyone, > > There have been a number of failures in the autobuilder today [1] [2] due > to the change currently sitting in master-next that switches > LAYERSERIES_COMPAT from honister to kirkstone[3]. > > Since the change will soon be merged into master I thought it'd be a good > idea to send an email so layer maintainers become aware of the upcoming > issue and update their corresponding layers accordingly. > > Cheers, > > Alejandro > > [1] https://swatbot.yoctoproject.org/mainindex/swat/ > [2] https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/3243 > [3] > https://git.yoctoproject.org/poky/commit/?h=master-next=7145b34de02fffa97bb1238f4777d817efcdc78f > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161936): https://lists.openembedded.org/g/openembedded-core/message/161936 Mute This Topic: https://lists.openembedded.org/mt/89230590/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] recipeutils: Add missing get_srcrev() call
Updates within bitbake now require this call to be triggered somewhere with
floating git source revs. Add the missing call. Issue can be reproduced with:
devtool check-upgrade-status dbus-wait
Signed-off-by: Richard Purdie
---
meta/lib/oe/recipeutils.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
index a0c6974f04a..872ff97b89a 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -1029,6 +1029,7 @@ def get_recipe_upstream_version(rd):
else:
ud = bb.fetch2.FetchData(src_uri, rd)
if rd.getVar("UPSTREAM_CHECK_COMMITS") == "1":
+bb.fetch2.get_srcrev(rd)
revision = ud.method.latest_revision(ud, rd, 'default')
upversion = pv
if revision != rd.getVar("SRCREV"):
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161935):
https://lists.openembedded.org/g/openembedded-core/message/161935
Mute This Topic: https://lists.openembedded.org/mt/89230461/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] convert-variables: Script for Inclusive Language variable renames
Richard Purdie writes: >> > This script searches for a list of variable that have been renamed >> > and converts them to their more descriptive names. s/descriptive/politically correct/ >> again: most of these renamings make identifiers much less descriptive >> because they now sound like boolean flags instead of lists > > Whilst you could say they sound like booleans, they clearly can't be > as that wouldn't make sense, e.g. "Ignoring variables in basehash" > makes no sense. True; because it does not make sense, these variables should not be named in this way. > Secondly, most metadata variables are lists of things. The renamed ones; yes. But when I look in bitbake.conf, I can not say that most variables are lists. > Adding "LIST" to every variable that is a list of items would just make > the variable names much longer with little end resulting readability > gain. True; explicit type annotations like in the hungarian notation are nonsense. But "whitelist" and "blacklist" are words with a meaning; the "list" is not used as a type annotation there. Variable names were perfectly readable. A change should make things better, not worse. > Unfortunately there likely isn't a perfect rename and these were the > best we were able to come up with. Why is the rename done at all? It makes the product just worse due to a less usable api and because it causes a lot of work for the users of the api (I shudder when I think about updating my CI to work with new and old branches). Enrico -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161941): https://lists.openembedded.org/g/openembedded-core/message/161941 Mute This Topic: https://lists.openembedded.org/mt/89199536/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCHv2] cmake: remove CMAKE_ASM_FLAGS variable in toolchain file
If you provide ASFLAGS CMake will already load them into CMAKE_AS_FLAGS
anyway, they will just not be force-overriden.
Martin
Am 17.02.22 um 20:46 schrieb Khem Raj:
On 2/17/22 7:57 AM, Martin Beeger wrote:
As discussied in [YOCTO #14717] cmake contains a OEToolchainConfig.cmake
file to configure the toolchain correctly in cross-compile build for
recipes
using cmake. The CMAKE_ASM_FLAGS are the configuration are meant for
assembly,
but the spelling is incorrect and the Flag is ASFLAGS for gcc and
other compilers.
So this variable might neever have worked and it is better for
recipes to specify their own.
Signed-off-by: Martin Beeger
---
meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake | 1 -
1 file changed, 1 deletion(-)
diff --git
a/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
b/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
index 86446c3ace..3ddef12c83 100644
--- a/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
+++ b/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
@@ -1,7 +1,6 @@
set( CMAKE_SYSTEM_NAME Linux )
set( CMAKE_C_FLAGS $ENV{CFLAGS} CACHE STRING "" FORCE )
set( CMAKE_CXX_FLAGS $ENV{CXXFLAGS} CACHE STRING "" FORCE )
-set( CMAKE_ASM_FLAGS ${CMAKE_C_FLAGS} CACHE STRING "" FORCE )
We do have global ASFLAGS so why not use that.
set( CMAKE_SYSROOT $ENV{OECORE_TARGET_SYSROOT} )
set( CMAKE_FIND_ROOT_PATH $ENV{OECORE_TARGET_SYSROOT} )
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161945):
https://lists.openembedded.org/g/openembedded-core/message/161945
Mute This Topic: https://lists.openembedded.org/mt/89212148/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] convert-variables: Script for Inclusive Language variable renames
On Fri, 2022-02-18 at 14:40 +0100, Enrico Scholz via lists.openembedded.org wrote: > "Saul Wold" writes: > > > From: Saul Wold > > > > This script searches for a list of variable that have been renamed > > and converts them to their more descriptive names. > > again: most of these renamings make identifiers much less descriptive > because they now sound like boolean flags instead of lists Whilst you could say they sound like booleans, they clearly can't be as that wouldn't make sense, e.g. "Ignoring variables in basehash" makes no sense. Secondly, most metadata variables are lists of things. Adding "LIST" to every variable that is a list of items would just make the variable names much longer with little end resulting readability gain. Unfortunately there likely isn't a perfect rename and these were the best we were able to come up with. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161938): https://lists.openembedded.org/g/openembedded-core/message/161938 Mute This Topic: https://lists.openembedded.org/mt/89199536/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage
On Thu, 2022-02-17 at 15:01 -0800, Saul Wold wrote: > I am working on a proposal to re-write how INCOMPATIBLE_LICENSES is used > and processed to possibly include a COMPATIBLE_LICENSES variable as > well, see PeterK's email [0] > > I am trying to determine the usage of WHITELIST_ which would be > used to override a license that might be listed in INCOMPATIBLE_LICENSES > variable. > > Randy and I have done a quick and dirty survey of a 100 or so layers > (thanks Randy) and could not find any real usage other than what's > currently in OE-Core for WHITELIST_GPL-3.0. > > If you are using WHITELIST_, please let me reply with your usage. > > > [0] https://lists.openembedded.org/g/openembedded-devel/message/95166 We need to be mindful that we need to resolve this to unblock the other language changes and feature creep here is potentially problematic. I do think it is worth trying to improve things rather than blindly allowing the horrible syntax in this variable to continue though. The test case we have for this currently is: WHITELIST_GPL-3.0:pn-core-image-minimal = "bash" so I'd wondered about an alternative of: INCOMPATIBLE_LICENSE_EXCEPTIONS:pn-core-image-minimal = "bash:GPL-3.0" which matches the current functionality, removes the issue that the name of the variable is unknown without iterating every possible license name and makes it clear where it is applying to. I don't really like INCOMPATIBLE_LICENSE_ALLOWED_RECIPES since: a) it is long b) it refers to recipes when it works against packages (INCOMPATIBLE_LICENSE_PACKAGE_EXCEPTIONS is more correct but still long) I do like it mentioning INCOMPATIBLE_LICENSE in full since it works in conjunction with that variable and that is definitely not clear from the current WHITELIST_XXX until you look at the code. I'm still of the opinion the AVAILABLE_LICENSES variable is something we should be aiming to remove ultimately too, it has horrible issues with layers changing hashes for all recipes. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161939): https://lists.openembedded.org/g/openembedded-core/message/161939 Mute This Topic: https://lists.openembedded.org/mt/89233023/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage
On Fri, 2022-02-18 at 14:13 +, Richard Purdie via lists.openembedded.org wrote: > On Thu, 2022-02-17 at 15:01 -0800, Saul Wold wrote: > > I am working on a proposal to re-write how INCOMPATIBLE_LICENSES is used > > and processed to possibly include a COMPATIBLE_LICENSES variable as > > well, see PeterK's email [0] > > > > I am trying to determine the usage of WHITELIST_ which would be > > used to override a license that might be listed in INCOMPATIBLE_LICENSES > > variable. > > > > Randy and I have done a quick and dirty survey of a 100 or so layers > > (thanks Randy) and could not find any real usage other than what's > > currently in OE-Core for WHITELIST_GPL-3.0. > > > > If you are using WHITELIST_, please let me reply with your usage. > > > > > > [0] https://lists.openembedded.org/g/openembedded-devel/message/95166 > > We need to be mindful that we need to resolve this to unblock the other > language > changes and feature creep here is potentially problematic. I do think it is > worth trying to improve things rather than blindly allowing the horrible > syntax > in this variable to continue though. > > The test case we have for this currently is: > > WHITELIST_GPL-3.0:pn-core-image-minimal = "bash" > > so I'd wondered about an alternative of: > > INCOMPATIBLE_LICENSE_EXCEPTIONS:pn-core-image-minimal = "bash:GPL-3.0" > > which matches the current functionality, removes the issue that the name of > the > variable is unknown without iterating every possible license name and makes it > clear where it is applying to. > > I don't really like INCOMPATIBLE_LICENSE_ALLOWED_RECIPES since: > > a) it is long > b) it refers to recipes when it works against packages Just as a warning, the code is actually confused. The base.bbclass code assumes it is a recipe name, the license_image code assumes it is a package name. All the more reason to come up with a standard and resolve this. My proposal stands but we need to decide if it is a recipe or package name that is listed (or both?). Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161940): https://lists.openembedded.org/g/openembedded-core/message/161940 Mute This Topic: https://lists.openembedded.org/mt/89233278/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [Openembedded-architecture] Kirkstone Layer Compatibility
Hello, +layer maintainers to ensure they see that. On 18/02/2022 12:37:04+0100, Martin Jansa wrote: > The [3] should be > https://git.openembedded.org/openembedded-core/commit/?id=311e61ae14b7216f5b98f1afe0e791644a07c9d0 > that's where LAYERSERIES_CORENAMES was changed to kirkstone (it's not due > to LAYERSERIES_COMPAT changes, these changes are what people need to update > in their layer). > > On Fri, Feb 18, 2022 at 7:57 AM Alejandro Hernandez Samaniego < > alejan...@enedino.org> wrote: > > > Hello everyone, > > > > There have been a number of failures in the autobuilder today [1] [2] due > > to the change currently sitting in master-next that switches > > LAYERSERIES_COMPAT from honister to kirkstone[3]. > > > > Since the change will soon be merged into master I thought it'd be a good > > idea to send an email so layer maintainers become aware of the upcoming > > issue and update their corresponding layers accordingly. > > > > Cheers, > > > > Alejandro > > > > [1] https://swatbot.yoctoproject.org/mainindex/swat/ > > [2] https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/3243 > > [3] > > https://git.yoctoproject.org/poky/commit/?h=master-next=7145b34de02fffa97bb1238f4777d817efcdc78f > > > > > > > > > > > > > > > -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161942): https://lists.openembedded.org/g/openembedded-core/message/161942 Mute This Topic: https://lists.openembedded.org/mt/89230590/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] convert-variables: Script for Inclusive Language variable renames
On Fri, 2022-02-18 at 15:27 +0100, Enrico Scholz wrote: > Richard Purdie writes: > > > > > This script searches for a list of variable that have been renamed > > > > and converts them to their more descriptive names. > > s/descriptive/politically correct/ We did try and make some of the names better describe what the variables do and make the variables more consistent. For example, a reference to HASHBASE was changed to BASEHASH which better matches every other reference to that thing in the code. The BB_ENV variables were also traditionally very confusing. Once you know, you know but for new users they weren't great. Also see the discussion about the license variable issues. I'm very consciously blocking the "simple" change as I want to see things improve. > Variable names were perfectly readable. A change should make things > better, not worse. See above, there are at least some changes which do. I'm sad you don't agree. > > Unfortunately there likely isn't a perfect rename and these were the > > best we were able to come up with. > > Why is the rename done at all? It makes the product just worse due to a > less usable api and because it causes a lot of work for the users of the > api (I shudder when I think about updating my CI to work with new and > old branches). For better or worse some of the terminology we have is offensive to some people. Obviously (and sadly) there will probably always be some element of something which someone could be offended by but these issues have come under a particular spotlight. People with far more experience of this than us have produced guidelines on the key issues, the priority of dealing with certain language and so on. We do have people wanting to try and improve things. Projects do need to be open to and able to change. If we don't try and take this input and help those people make such changes where appropriate, we'll just alienate and frustrate more users even if those users were not personally offended by the language, a kind of "rot" can set in to our community. I do not want to see that. I have advised caution all the way through this. Should the project get this wrong, the potential for negative social media feedback against the project is huge. For me personally, there is also a huge risk should I "misstep" in handling this. The potential to break things for users is also really high, I realise that. I have done a lot of work to try and make sure issues are at least clearly reported to users with some idea of how to resolve them so the transition is less painful. I do have some experience of making changes to the project and am trying my best to use that to our benefit. At this stage, rightly or wrongly (I make no judgement) the project cannot afford not to make these changes. The best thing we can do is to try and reduce the impact on users as best we can. In doing so, we also make the project's values very clear. We do not mean any offence by the language we've had, we just didn't realise the issues. Now we are aware, we're doing our best to correct it. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161944): https://lists.openembedded.org/g/openembedded-core/message/161944 Mute This Topic: https://lists.openembedded.org/mt/89199536/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] convert-variables: Script for Inclusive Language variable renames
On Fri, 18 Feb 2022 at 15:27, Enrico Scholz via lists.openembedded.org wrote: > > Unfortunately there likely isn't a perfect rename and these were the > > best we were able to come up with. > > Why is the rename done at all? It makes the product just worse due to a > less usable api and because it causes a lot of work for the users of the > api (I shudder when I think about updating my CI to work with new and > old branches). Enrico, cut this out please. Every time you start with a specific, kind of valid, question, then turn it into a rant about how the whole effort is useless or worse. People simply will stop answering you if this carries on. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161943): https://lists.openembedded.org/g/openembedded-core/message/161943 Mute This Topic: https://lists.openembedded.org/mt/89199536/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] convert-variables: Script for Inclusive Language variable renames
"Saul Wold" writes: > From: Saul Wold > > This script searches for a list of variable that have been renamed > and converts them to their more descriptive names. again: most of these renamings make identifiers much less descriptive because they now sound like boolean flags instead of lists > +"BB_SETSCENE_ENFORCE_WHITELIST":"BB_SETSCENE_ENFORCE_IGNORE_TASKS", > +"BB_HASHBASE_WHITELIST":"BB_BASEHASH_IGNORE_VARS", > +"BB_HASHTASK_WHITELIST":"BB_TASKHASH_IGNORE_TASKS", > +"CVE_CHECK_PN_WHITELIST":"CVE_CHECK_SKIP_RECIPE", > +"CVE_CHECK_WHITELIST":"CVE_CHECK_IGNORE", > +"MULTI_PROVIDER_WHITELIST":"BB_MULTI_PROVIDER_ALLOWED", > +"PNBLACKLIST":"SKIP_RECIPE", > +"SDK_LOCAL_CONF_BLACKLIST":"ESDK_LOCAL_CONF_ALLOW", > +"SDK_LOCAL_CONF_WHITELIST":"ESDK_LOCAL_CONF_REMOVE", > +"SDK_INHERIT_BLACKLIST":"ESDK_CLASS_INHERIT_DISABLE", > +"SSTATE_DUPWHITELIST":"SSTATE_ALLOW_OVERLAP_FILES", > +"SYSROOT_DIRS_BLACKLIST":"SYSROOT_DIRS_IGNORE", > +"UNKNOWN_CONFIGURE_WHITELIST":"UNKNOWN_CONFIGURE_OPT_IGNORE", Enrico -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161937): https://lists.openembedded.org/g/openembedded-core/message/161937 Mute This Topic: https://lists.openembedded.org/mt/89199536/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/2] scripts: Add a conversion script to use SPDX license names
We're standardising on SPDX license names so it is overdue to change
the ones in the LICENSE fileds to the SPDX values. Add a conversion
script which makes this straightforward on the most part.
Ultimately this allows the core code to be more efficient and not need
to consult the mappings.
Signed-off-by: Richard Purdie
---
scripts/contrib/convert-spdx-licenses.py | 144 +++
1 file changed, 144 insertions(+)
create mode 100755 scripts/contrib/convert-spdx-licenses.py
diff --git a/scripts/contrib/convert-spdx-licenses.py
b/scripts/contrib/convert-spdx-licenses.py
new file mode 100755
index 000..09418f4050e
--- /dev/null
+++ b/scripts/contrib/convert-spdx-licenses.py
@@ -0,0 +1,144 @@
+#!/usr/bin/env python3
+#
+# Conversion script to change LICENSE entries to SPDX identifiers
+#
+# Copyright (C) 2021-2022 Richard Purdie
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+import re
+import os
+import sys
+import tempfile
+import shutil
+import mimetypes
+
+if len(sys.argv) < 2:
+print("Please specify a directory to run the conversion script against.")
+sys.exit(1)
+
+license_map = {
+"AGPL-3" : "AGPL-3.0-only",
+"AGPL-3+" : "AGPL-3.0-or-later",
+"AGPLv3" : "AGPL-3.0-only",
+"AGPLv3+" : "AGPL-3.0-or-later",
+"AGPLv3.0" : "AGPL-3.0-only",
+"AGPLv3.0+" : "AGPL-3.0-or-later",
+"AGPL-3.0" : "AGPL-3.0-only",
+"AGPL-3.0+" : "AGPL-3.0-or-later",
+"BSD-0-Clause" : "0BSD",
+"GPL-1" : "GPL-1.0-only",
+"GPL-1+" : "GPL-1.0-or-later",
+"GPLv1" : "GPL-1.0-only",
+"GPLv1+" : "GPL-1.0-or-later",
+"GPLv1.0" : "GPL-1.0-only",
+"GPLv1.0+" : "GPL-1.0-or-later",
+"GPL-1.0" : "GPL-1.0-only",
+"GPL-1.0+" : "GPL-1.0-or-later",
+"GPL-2" : "GPL-2.0-only",
+"GPL-2+" : "GPL-2.0-or-later",
+"GPLv2" : "GPL-2.0-only",
+"GPLv2+" : "GPL-2.0-or-later",
+"GPLv2.0" : "GPL-2.0-only",
+"GPLv2.0+" : "GPL-2.0-or-later",
+"GPL-2.0" : "GPL-2.0-only",
+"GPL-2.0+" : "GPL-2.0-or-later",
+"GPL-3" : "GPL-3.0-only",
+"GPL-3+" : "GPL-3.0-or-later",
+"GPLv3" : "GPL-3.0-only",
+"GPLv3+" : "GPL-3.0-or-later",
+"GPLv3.0" : "GPL-3.0-only",
+"GPLv3.0+" : "GPL-3.0-or-later",
+"GPL-3.0" : "GPL-3.0-only",
+"GPL-3.0+" : "GPL-3.0-or-later",
+"LGPLv2" : "LGPL-2.0-only",
+"LGPLv2+" : "LGPL-2.0-or-later",
+"LGPLv2.0" : "LGPL-2.0-only",
+"LGPLv2.0+" : "LGPL-2.0-or-later",
+"LGPL-2.0" : "LGPL-2.0-only",
+"LGPL-2.0+" : "LGPL-2.0-or-later",
+"LGPL2.1" : "LGPL-2.1-only",
+"LGPL2.1+" : "LGPL-2.1-or-later",
+"LGPLv2.1" : "LGPL-2.1-only",
+"LGPLv2.1+" : "LGPL-2.1-or-later",
+"LGPL-2.1" : "LGPL-2.1-only",
+"LGPL-2.1+" : "LGPL-2.1-or-later",
+"LGPLv3" : "LGPL-3.0-only",
+"LGPLv3+" : "LGPL-3.0-or-later",
+"LGPL-3.0" : "LGPL-3.0-only",
+"LGPL-3.0+" : "LGPL-3.0-or-later",
+"MPL-1" : "MPL-1.0",
+"MPLv1" : "MPL-1.0",
+"MPLv1.1" : "MPL-1.1",
+"MPLv2" : "MPL-2.0",
+"MIT-X" : "MIT",
+"MIT-style" : "MIT",
+"openssl" : "OpenSSL",
+"PSF" : "PSF-2.0",
+"PSFv2" : "PSF-2.0",
+"Python-2" : "Python-2.0",
+"Apachev2" : "Apache-2.0",
+"Apache-2" : "Apache-2.0",
+"Artisticv1" : "Artistic-1.0",
+"Artistic-1" : "Artistic-1.0",
+"AFL-2" : "AFL-2.0",
+"AFL-1" : "AFL-1.2",
+"AFLv2" : "AFL-2.0",
+"AFLv1" : "AFL-1.2",
+"CDDLv1" : "CDDL-1.0",
+"CDDL-1" : "CDDL-1.0",
+"EPLv1.0" : "EPL-1.0",
+"FreeType" : "FTL",
+"Nauman" : "Naumen",
+"tcl" : "TCL",
+"vim" : "Vim",
+"SGIv1" : "SGI-1",
+}
+
+def processfile(fn):
+print("processing file '%s'" % fn)
+try:
+fh, abs_path = tempfile.mkstemp()
+modified = False
+with os.fdopen(fh, 'w') as new_file:
+with open(fn, "r") as old_file:
+for line in old_file:
+if not line.startswith("LICENSE"):
+new_file.write(line)
+continue
+orig = line
+for license in sorted(license_map, key=len, reverse=True):
+for ending in ['"', "'", " "]:
+line = line.replace(license + ending,
license_map[license] + ending)
+if orig != line:
+modified = True
+new_file.write(line)
+if modified:
+shutil.copymode(fn, abs_path)
+os.remove(fn)
+shutil.move(abs_path, fn)
+except UnicodeDecodeError:
+pass
+
+ourname = os.path.basename(sys.argv[0])
+ourversion = "0.01"
+
+if os.path.isfile(sys.argv[1]):
+processfile(sys.argv[1])
+sys.exit(0)
+
+for targetdir in sys.argv[1:]:
+print("processing directory '%s'" % targetdir)
+for root, dirs, files in os.walk(targetdir):
+for name in files:
+if name == ourname:
+continue
+fn = os.path.join(root, name)
+if os.path.islink(fn):
+continue
+if "/.git/" in fn or fn.endswith(".html") or fn.endswith(".patch")
or fn.endswith(".m4") or fn.endswith(".diff") or fn.endswith(".orig"):
+continue
+processfile(fn)
+
+print("All files processed with version %s" %
[OE-core] [PATCH] Revert "patch.py: Initialize git repo before patching"
This reverts commit 6184b56a7a0fc6f5d19fdfb81e7453667f7da940.
The above commit breaks building of recipes where sources are checked out from
Git and PATCHTOOL = "git". The do_patch tasks fails before applying the
first patch without any helpful error messages.
GitApplyTree::_isInitialized():
+ cmd = "git rev-parse --show-toplevel"
+ (status, output) = subprocess.getstatusoutput(cmd.split())
The cmd.split() expression effectively runs GIT without any arguments.
Using `subprocess.getstatusoutput(cmd)` seems to work.
+ ## Make sure repo is in builddir to not break top-level git repos
+ return status == 0 and os.path.samedir(output, self.dir)
Exception: AttributeError: module 'posixpath' has no attribute 'samedir'
GitApplyTree::_initRepo():
+ runcmd("git init".split(), self.dir)
+ runcmd("git add .".split(), self.dir)
+ runcmd("git commit -a --allow-empty -m Patching_started".split(),
self.dir)
If _isInitialized() returned false although there is actually an initialized
GIT repo, the last command fails with 128.
Signed-off-by: Christian Eggers
---
The "git commit" command fails only on my CI machine but not on my dev system
(couldn't figure out why). This means that on both systems the existing GIT
respository is erroneously reinitialized, but on the CI this breaks the build
while on the dev machine the error is not noticeable.
meta/lib/oe/patch.py| 16 +---
meta/lib/oeqa/selftest/cases/bbtests.py | 15 ---
2 files changed, 1 insertion(+), 30 deletions(-)
diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index 950fe723dcfd..fccbedb519d7 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -4,7 +4,6 @@
import oe.path
import oe.types
-import subprocess
class NotFoundError(bb.BBHandledException):
def __init__(self, path):
@@ -26,6 +25,7 @@ class CmdError(bb.BBHandledException):
def runcmd(args, dir = None):
import pipes
+import subprocess
if dir:
olddir = os.path.abspath(os.curdir)
@@ -56,7 +56,6 @@ def runcmd(args, dir = None):
if dir:
os.chdir(olddir)
-
class PatchError(Exception):
def __init__(self, msg):
self.msg = msg
@@ -299,19 +298,6 @@ class GitApplyTree(PatchTree):
PatchTree.__init__(self, dir, d)
self.commituser = d.getVar('PATCH_GIT_USER_NAME')
self.commitemail = d.getVar('PATCH_GIT_USER_EMAIL')
-if not self._isInitialized():
-self._initRepo()
-
-def _isInitialized(self):
-cmd = "git rev-parse --show-toplevel"
-(status, output) = subprocess.getstatusoutput(cmd.split())
-## Make sure repo is in builddir to not break top-level git repos
-return status == 0 and os.path.samedir(output, self.dir)
-
-def _initRepo(self):
-runcmd("git init".split(), self.dir)
-runcmd("git add .".split(), self.dir)
-runcmd("git commit -a --allow-empty -m Patching_started".split(),
self.dir)
@staticmethod
def extractPatchHeader(patchfile):
diff --git a/meta/lib/oeqa/selftest/cases/bbtests.py
b/meta/lib/oeqa/selftest/cases/bbtests.py
index e2b9290200ac..487568c907e5 100644
--- a/meta/lib/oeqa/selftest/cases/bbtests.py
+++ b/meta/lib/oeqa/selftest/cases/bbtests.py
@@ -298,21 +298,6 @@ INHERIT:remove = \"report-error\"
test_recipe_summary_after = get_bb_var('SUMMARY', test_recipe)
self.assertEqual(expected_recipe_summary, test_recipe_summary_after)
-def test_git_patchtool(self):
-""" PATCHTOOL=git should work with non-git sources like tarballs
-test recipe for the test must NOT containt git:// repository in
SRC_URI
-"""
-test_recipe = "man-db"
-self.write_recipeinc(test_recipe, 'PATCHTOOL=\"git\"')
-src = get_bb_var("SRC_URI",test_recipe)
-gitscm = re.search("git://", src)
-self.assertFalse(gitscm, "test_git_patchtool pre-condition failed: {}
test recipe contains git repo!".format(test_recipe))
-result = bitbake('man-db -c patch', ignore_status=False)
-fatal = re.search("fatal: not a git repository (or any of the parent
directories)", result.output)
-self.assertFalse(fatal, "Failed to patch using PATCHTOOL=\"git\"")
-self.delete_recipeinc(test_recipe)
-bitbake('-cclean man-db')
-
def test_git_unpack_nonetwork(self):
"""
Test that a recipe with a floating tag that needs to be resolved
upstream doesn't
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161948):
https://lists.openembedded.org/g/openembedded-core/message/161948
Mute This Topic: https://lists.openembedded.org/mt/89238057/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Typo in comment (was: tool to list source files)
On Thu, 2022-02-17 at 17:39 -0600, Joseph Reynolds wrote: > There seems to a typo in a comment in archiver.bbclass; ARCHIVE_MODE > should be ARCHIVER_MODE for "mirror" (letter R is missing). > > https://github.com/openembedded/openembedded-core/blob/master/meta/classes/archiver.bbclass#L8 > > Joseph > > P.S. The archiver class is awesome. Thank you! > I fixed that typo, thanks for reporting. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161949): https://lists.openembedded.org/g/openembedded-core/message/161949 Mute This Topic: https://lists.openembedded.org/mt/89222366/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] convert-variables: Script for Inclusive Language variable renames
Richard Purdie writes:
>> > > > This script searches for a list of variable that have been renamed
>> > > > and converts them to their more descriptive names.
>>
>> s/descriptive/politically correct/
>
> We did try and make some of the names better describe what the variables
> do and make the variables more consistent.
>
> For example, a reference to HASHBASE was changed to BASEHASH which
> better matches every other reference to that thing in the code.
When you really feel that this Yoda style naming must be fixed; then ok.
But for me, the gain would not be large enough to break the api.
> The BB_ENV variables were also traditionally very confusing. Once you
> know, you know but for new users they weren't great.
The new naming is much more confusing. While this kind of operation
(exclude or include something) was previously named by "whitelist" +
"blacklist" more or less consistently, it is scattered around across
multiple variants now.
Especially for the hash related lists, searching for "whitelist" or
"blacklist" in the sources revealed often the right way how to do
things.
> Also see the discussion about the license variable issues. I'm very
> consciously blocking the "simple" change as I want to see things
> improve.
>
>> Variable names were perfectly readable. A change should make things
>> better, not worse.
>
> See above, there are at least some changes which do. I'm sad you don't
> agree.
ok; some changes are ok. E.g.
| "PNBLACKLIST":"SKIP_RECIPE",
because former name is misleading (it is not really a list/set but has
some specially addressing by varflags).
>> Why is the rename done at all? It makes the product just worse due to a
>> less usable api and because it causes a lot of work for the users of the
>> api (I shudder when I think about updating my CI to work with new and
>> old branches).
>
> For better or worse some of the terminology we have is offensive to
> some people.
Is there any real-world evidence that this is really the case? Especially
the embedded sector is filled with blacklisted terms (i2c master/slave,
spi mosi/miso) so I do not think that somebody is really offended.
In the opposite, I feel offended when such changes are labeled as
(technical) improvements ("more descriptive names").
> Obviously (and sadly) there will probably always be some element of
> something which someone could be offended by but these issues have
> come under a particular spotlight. People with far more experience of
> this than us have produced guidelines on the key issues,
In my experience, such people have too much spare time and invented a
problem only to come up with a solution later.
> We do have people wanting to try and improve things. Projects do
> need to be open to and able to change. If we don't try and take this
> input and help those people make such changes where appropriate,
> we'll just alienate and frustrate more users even if those users
> were not personally offended by the language, a kind of "rot" can
> set in to our community. I do not want to see that
I see a much higher risk when significant changes are done due to
political reasons rather than technical ones.
> I have advised caution all the way through this. Should the project
> get this wrong, the potential for negative social media feedback
> against the project is huge.
Does such negative social media feedback really exist resp. does it
exist in channels that are relevant to us?
Linux kernel has not "cleaned" its api either and just said that future
development should avoid certain terms. I can not remember any negative
feedback.
Just do the same here: avoid some terms in future development and when
there are really technical reasons to touch existing variables, then
rename them.
> For me personally, there is also a huge risk should I "misstep" in
> handling this. The potential to break things for users is also really
> high, I realise that. I have done a lot of work to try and make sure
> issues are at least clearly reported to users with some idea of how
> to resolve them so the transition is less painful. I do have some
> experience of making changes to the project and am trying my best to
> use that to our benefit.
You are doing a great job, but the project evolved beautiful over the
last >15 years with the old identifier and I can not remember any
complaints about them.
Enrico
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161950):
https://lists.openembedded.org/g/openembedded-core/message/161950
Mute This Topic: https://lists.openembedded.org/mt/89199536/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
