Hello Fabien Thomas, I hope you are doing well. Just a gentle follow-up on my previous email regarding CVE-2026-58055. When you have a chance, could you please share your thoughts on the validation approach for a backport in this case? I would appreciate any guidance you can provide. Thank you for your time. Best regards, Deepak ________________________________ From: Deepak Rathore -X (deeratho - E INFOCHIPS PRIVATE LIMITED at Cisco) <[email protected]> Sent: Thursday, August 13, 2026 11:34 AM To: Fabien Thomas <[email protected]>; [email protected] <[email protected]> Cc: Viral Chavda (vchavda) <[email protected]> Subject: Re: [OE-core][wrynose][PATCH] nghttp2: set status for CVE-2026-58055
Hello Fabien, Thank you for highlighting the risk of checking EXTRA_OECMAKE directly. I agree that a user could modify the CMake options through a .bbappend while the original -DENABLE_LIB_ONLY=ON option remains present. In that case, the conditional CVE_STATUS could produce a misleading result. I tested the complete upstream fix against nghttp2 1.68.1 with patch fuzz disabled: https://github.com/nghttp2/nghttp2/commit/ab28105c4a0197da24f8bfc414bc116055249e1e Unfortunately, it is not a clean or straightforward backport. Thirteen hunks fail across six nghttpx source files because the fix was developed after substantial nghttpx refactoring that was included in the 1.70.0 release. The current OE-Core recipe intentionally builds only libnghttp2 using -DENABLE_LIB_ONLY=ON. Consequently, nghttpx and the affected shrpx sources are not compiled by the default recipe. This behavior was introduced when the recipe was converted to a library-only recipe. To validate a manual backport, I would need to use a temporary local .bbappend that: - adds the nghttpx build dependencies; - disables ENABLE_LIB_ONLY; - enables ENABLE_APP; - builds nghttpx with the backported patch. I also have a question regarding validation: since nghttpx is not enabled by the recipe’s default configuration, how would the community normally validate changes to this disabled component? Thank you for your guidance. Best regards, Deepak ________________________________ From: Fabien Thomas <[email protected]> Sent: Wednesday, August 12, 2026 9:07 PM To: Deepak Rathore -X (deeratho - E INFOCHIPS PRIVATE LIMITED at Cisco) <[email protected]>; [email protected] <[email protected]> Subject: Re: [OE-core][wrynose][PATCH] nghttp2: set status for CVE-2026-58055 On Wed Aug 5, 2026 at 10:03 AM CEST, Deepak Rathore via lists.openembedded.org wrote: > From: Deepak Rathore <[email protected]> > > CVE-2026-58055 affects the nghttpx proxy when forwarding HTTP/1.1 > Upgrade requests with a Content-Length header and body. > > The default recipe does not build nghttpx. Add a conditional > CVE_STATUS entry so the CVE remains unpatched if app support is > enabled, while default builds are marked not-applicable-config. > > References: > https://nvd.nist.gov/vuln/detail/CVE-2026-58055 > > Signed-off-by: Deepak Rathore <[email protected]> > --- > meta/recipes-support/nghttp2/nghttp2_1.68.1.bb | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/meta/recipes-support/nghttp2/nghttp2_1.68.1.bb > b/meta/recipes-support/nghttp2/nghttp2_1.68.1.bb > index 71d5eef8d6..29a7d26819 100644 > --- a/meta/recipes-support/nghttp2/nghttp2_1.68.1.bb > +++ b/meta/recipes-support/nghttp2/nghttp2_1.68.1.bb > @@ -17,4 +17,6 @@ PACKAGECONFIG[manpages] = "-DENABLE_DOC=ON,-DENABLE_DOC=OFF" > > EXTRA_OECMAKE = "-DENABLE_LIB_ONLY=ON -DENABLE_PYTHON_BINDINGS=OFF" > > +CVE_STATUS[CVE-2026-58055] = "${@bb.utils.contains('EXTRA_OECMAKE', > '-DENABLE_LIB_ONLY=ON', 'not-applicable-config: nghttpx proxy is not built in > the default nghttp2 configuration', 'unpatched', d)}" > + > BBCLASSEXTEND = "native nativesdk" Hello Deepak, I'm filling in for Yoann while he's on leave. We would prefer to avoid conditional CVE_STATUS entries whenever possible. The risk is that users who enable this feature through other means think they are protected but actually no. Conditional CVE_STATUS should really be a last resort. Could you please check if the actual fix for CVE-2026-58055 can be easily backported instead? Best regards -- Fabien Thomas Smile ECS
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#243727): https://lists.openembedded.org/g/openembedded-core/message/243727 Mute This Topic: https://lists.openembedded.org/mt/120607272/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
