On Fri, Sep 11, 2026 at 06:19 PM, Yoann Congal wrote:

On Fri Sep 11, 2026 at 2:46 PM CEST, Yoann Congal wrote:

On Wed Aug 26, 2026 at 10:12 AM CEST, Hetvi Thakar -X (hthakar - E INFOCHIPS PRIVATE LIMITED at Cisco) via lists.openembedded.org wrote:

From: Hetvi Thakar <hthakar@cisco.com>

Analysis:
- CVE-2024-42040 affects the U-Boot DHCP client in net/bootp.c [1].
- u-boot-tools uses tools-only_defconfig, where CONFIG_NET is disabled
[2].
- Hence ignore this CVE for u-boot-tools; the exclusion is
configuration-based.

Reference:
[1] https://nvd.nist.gov/vuln/detail/CVE-2024-42040
[2] https://github.com/u-boot/u-boot/blob/866ca972d6c3/configs/tools-only_defconfig

Signed-off-by: Hetvi Thakar <hthakar@cisco.com>
---
meta/recipes-bsp/u-boot/u-boot-tools_2024.01.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2024.01.bb b/meta/recipes-bsp/u-boot/u-boot-tools_2024.01.bb
index 4b6d89ed4e..b5711e1f97 100644
--- a/meta/recipes-bsp/u-boot/u-boot-tools_2024.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-tools_2024.01.bb
@@ -2,3 +2,5 @@ require u-boot-common.inc
require u-boot-tools.inc

SRC_URI += "file://CVE-2026-46728.patch"
+
+CVE_STATUS[CVE-2024-42040] = "not-applicable-config: DHCP client code in net/bootp.c is not built by tools-only_defconfig, which disables CONFIG_NET."

Hello,

I don't think we need this because, even if the code is not compiled, it
has been fixed earlier in scarthgap:
See 5c086db3f44 (u-boot: fix CVE-2024-42040, 2025-10-29)
Same reasonning apply to other patches in this series. Can you check if
we really need those?

Thanks!

In the meantime, I took 1/11 in my branch and held the rest (2-11/11).
Be aware of this if you send a new series.

Hi Yoann,

Thanks for pointing this out.

The referenced fix was initially added in u-boot-common.inc, where
it applied to both u-boot and u-boot-tools. It was later moved to
u-boot.inc [1], so it now applies only to the u-boot recipe and
not to u-boot-tools.

u-boot-tools does not inherit u-boot.inc; it uses
u-boot-common.inc and u-boot-tools.inc. Therefore, the existing
CVE status is no longer applied to u-boot-tools.

The CVE is still reported against u-boot-tools because its
CVE_PRODUCT [2] maps to the U-Boot product. However, u-boot-tools
uses tools-only_defconfig, where CONFIG_NET is disabled, so the
vulnerable DHCP client code in net/bootp.c is not compiled.

Therefore, the proposed change only adds a recipe-specific CVE status
for u-boot-tools; it does not duplicate the source fix.

I also noticed Peter's proposed change [3], which moves these CVE
patches from u-boot.inc to u-boot-common.inc. Since
u-boot-common.inc is inherited by both u-boot and u-boot-tools,
this would cause all of those patches to be applied to u-boot-tools
as well.

I don't think this move is necessary, since not all of the affected
code is built by u-boot-tools. The actual source fixes should remain
with u-boot, where they are required. For u-boot-tools, the CVEs
whose vulnerable code is not compiled can instead be handled with the
appropriate CVE_STATUS entries.

References:
[1] https://git.openembedded.org/openembedded-core/commit/?h=scarthgap&id=f4ced8ff03147dd532a88cf3ce08d61fab057522
[2] https://git.openembedded.org/openembedded-core/commit/?h=scarthgap&id=9170fe393c379b9161a8843506420269f5b53e40
[3] https://patchwork.yoctoproject.org/project/oe-core/patch/20260923173850.21338-1-peter.marko@siemens.com/

Regards,
Hetvi

Thanks!
--
Yoann Congal
Smile ECS