Re: [OE-core] [scarthgap][PATCH] u-boot-tools: use all patches from u-boot

["Yoann Congal" <yoann.congal@smile.fr>]

On Tue Nov 3, 2026 at 6:33 AM CET, Hetvi Thakar -X (hthakar - E INFOCHIPS PRIVATE LIMITED at Cisco) wrote:
> Hi Yoann,
>
> My reason for adding CVE_STATUS for is that u-boot-tools uses
> tools-only_defconfig, which disables networking. The affected TCP and
> NFS code is therefore not compiled into the tools.
> not-applicable-config accurately describes this configuration.
>
> I understand the preference for sharing source patches between u-boot
> and u-boot-tools. However, the tools remain unaffected by these CVEs
> regardless of whether the source fixes are applied, so I believe the
> configuration exclusions are technically valid.
>
> The same approach is already used in the wrynose branch [1], which
> excludes all three CVEs. The fix for CVE-2026-29009 was also applied
> separately to u-boot on wrynose [2].
> Additionally, For CVE-2026-29007 and CVE-2026-29008, I have not
> located a merged upstream fix or a formal patch submission for either
> CVE in the U-Boot community.
>
> For these reasons, I believe retaining the CVE_STATUS entries is
> appropriate for u-boot-tools on Scarthgap. They accurately reflect the
> configuration being built and keep the CVE assessment consistent with
> the approach already accepted for Wrynose.

The new proposed approach would have to be deployed on wrynose as well
(if applicable, I have not checked).

I think that having the precise reason for a non-applicable CVE is not
worth doing the CVE work twice (once with a patch, once with the
CVE_STATUS). If we can fix both u-boot/u-boot-tools with a single patch
it's more efficient.

I still think we should merge the sources (upstream+patches) between
u-boot/u-boot-tools and fix the CVEs only once if possible.

>
> [1] https://github.com/openembedded/openembedded-core/blob/wrynose/meta/recipes-bsp/u-boot/u-boot-tools_2026.01.bb
> [2] https://git.openembedded.org/openembedded-core/commit/?h=wrynose&id=dff41dcd5e54cad46ba91ecc45faefb0c8db9089
>
> Regards,
> Hetvi
> ________________________________
> From: Yoann Congal <yoann.congal@smile.fr>
> Sent: 28 October 2026 16:26
> To: Hetvi Thakar -X (hthakar - E INFOCHIPS PRIVATE LIMITED at Cisco) <hthakar@cisco.com>; peter.marko@siemens.com <peter.marko@siemens.com>; openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org>
> Subject: Re: [OE-core] [scarthgap][PATCH] u-boot-tools: use all patches from u-boot
>
> On Wed Oct 28, 2026 at 11:04 AM CET, Hetvi Thakar -X (hthakar - E INFOCHIPS PRIVATE LIMITED at Cisco) wrote:
>> Hi Yoann,
>>
>> Thanks for clarifying. For patches 9–11, I understand that source
>> fixes are preferred. However, networking is disabled in u-boot-tools,
>> so building it would not compile or exercise the affected code. How
>> should these fixes be verified?
>
> By sharing the sources with u-boot which will compile those parts.
>
>>
>> Regards,
>> Hetvi
>>
>> ________________________________
>> From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> on behalf of Yoann Congal via lists.openembedded.org <yoann.congal=smile.fr@lists.openembedded.org>
>> Sent: 28 October 2026 14:37
>> To: Hetvi Thakar -X (hthakar - E INFOCHIPS PRIVATE LIMITED at Cisco) <hthakar@cisco.com>; peter.marko@siemens.com <peter.marko@siemens.com>; openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org>
>> Subject: Re: [OE-core] [scarthgap][PATCH] u-boot-tools: use all patches from u-boot
>>
>> On Tue Oct 20, 2026 at 7:16 AM CEST, Hetvi Thakar -X (hthakar - E INFOCHIPS PRIVATE LIMITED at Cisco) wrote:
>>> Hi Yoann, Peter,
>>>
>>> Thanks, Yoann. Continuing the discussion here as suggested.
>>>
>>> As i explained in the other thread [1], the existing u-boot fixes are
>>> not currently applied to u-boot-tools. My CVE_STATUS changes address
>>> cases where the affected code is not compiled into the tools build.
>>>
>>> I understand that the proposed separate include would allow both
>>> recipes to share the CVE patches without adding them to
>>> u-boot-common.inc and affecting downstream users.
>>>
>>> My concern is whether we need this additional include and shared patch
>>> list for cases that can be handled through recipe-specific CVE_STATUS
>>> entries. Could we consider the held exclusions on that basis?
>>>
>>> If maintaining one shared source patch set is the preferred approach,
>>> could you clarify how we should handle patches 2–11 of my series?
>>> Should we revisit them after the shared include is settled and retain
>>> only the exclusions still needed?
>>
>> The general idea is that by sharing CVE patches with the main u-boot
>> recipe, CVE would be also "fixed" in u-boot-tools (even if said patch is
>> not compiled).
>>
>> For 2-8, patches are in u-boot so no need to ignore them:
>> * [Patch 02/11] u-boot-tools: Ignore CVE-2024-42040
>> * [Patch 03/11] u-boot-tools: Ignore CVE-2024-57254
>> * [Patch 04/11] u-boot-tools: Ignore CVE-2024-57255
>> * [Patch 05/11] u-boot-tools: Ignore CVE-2024-57256
>> * [Patch 06/11] u-boot-tools: Ignore CVE-2024-57257
>> * [Patch 07/11] u-boot-tools: Ignore CVE-2024-57258
>> * [Patch 08/11] u-boot-tools: Ignore CVE-2024-57259
>>
>> For 9-11, there are no u-boot patches so ignoring them in the
>> u-boot-tools recipe, would be fair (but patching them would be
>> preferable):
>> * [Patch 09/11] u-boot-tools: Ignore CVE-2026-29007
>> * [Patch 10/11] u-boot-tools: Ignore CVE-2026-29008
>> * [Patch 11/11] u-boot-tools: Ignore CVE-2026-29009
>>
>> Regards,
>>
>>>
>>> [1] https://lists.openembedded.org/g/openembedded-core/message/247868
>>>
>>> Regards,
>>> Hetvi
>>> ________________________________
>>> From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> on behalf of Yoann Congal via lists.openembedded.org <yoann.congal=smile.fr@lists.openembedded.org>
>>> Sent: 16 October 2026 03:44
>>> To: peter.marko@siemens.com <peter.marko@siemens.com>; openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org>
>>> Cc: Hetvi Thakar -X (hthakar - E INFOCHIPS PRIVATE LIMITED at Cisco) <hthakar@cisco.com>
>>> Subject: Re: [OE-core] [scarthgap][PATCH] u-boot-tools: use all patches from u-boot
>>>
>>> On Wed Sep 23, 2026 at 7:38 PM CEST, Peter Marko via lists.openembedded.org wrote:
>>>> From: Peter Marko <peter.marko@siemens.com>
>>>>
>>>> After sharing CVE_PRODUCT between u-boot and u-boot-tools CVEs
>>>> patched in u-boot showed-up in CVE reports for u-boot-tools.
>>>>
>>>> It does not make much sense to share git repository but not share all
>>>> patches on top of it, so move adding all patches from u-boot recipe to a
>>>> common include file where also the git repository is defined.
>>>>
>>>> Signed-off-by: Peter Marko <peter.marko@siemens.com>
>>>> ---
>>>>  meta/recipes-bsp/u-boot/u-boot-common.inc       | 10 ++++++++++
>>>>  meta/recipes-bsp/u-boot/u-boot-tools_2024.01.bb |  2 --
>>>>  meta/recipes-bsp/u-boot/u-boot_2024.01.bb       | 12 ------------
>>>>  3 files changed, 10 insertions(+), 14 deletions(-)
>>>
>>> Hello Peter, Hetvi,
>>>
>>> There is a bit of back-and-forth around u-boot-common.inc. So I thought I
>>> would give my vision and get your thoughts.
>>>
>>> Fundamentally, there is confusion about the usage of this .inc file:
>>> * This is the common part of u-boot and u-boot-tools recipes (what the
>>>   above patch uses)
>>> * But, also, this may be used by downstream layers to reuse u-boot
>>>   recipe parts. We basically did the revert of Peter's patch a few month
>>>   ago for this reason[0].
>>>
>>> With Paul, we would like to have a single set of patches common for both
>>> u-boot and u-boot-tools, but that can't be in u-boot-common.inc as there
>>> is a risk of breaking downstream layers.
>>>
>>> Our idea is to create a new inc file "u-boot-common-patches.inc" (I'm
>>> not attached to the name) that contains only SRC_URI += "CVE_*.patch"
>>> and a big warning explaining that is file is only supposed to be
>>> included from layer-local recipes (namely u-boot and u-boot-tools).
>>>
>>> This whole situation is not ideal but think the above would solve our
>>> issues and still be acceptable under stable policy.
>>>
>>> What do you think?
>>>
>>> Regards,
>>>
>>> [0]: u-boot: move CVE patches out of the common .inc file - openembedded-core - OpenEmbedded Core layer
>>>      https://git.openembedded.org/openembedded-core/commit/?id=f4ced8ff03147dd532a88cf3ce08d61fab057522
>>> --
>>> Yoann Congal
>>> Smile ECS
>>
>>
>> --
>> Yoann Congal
>> Smile ECS
>
>
> --
> Yoann Congal
> Smile ECS


-- 
Yoann Congal
Smile ECS