On Wed Aug 19, 2026 at 1:45 PM CEST, Deepak Rathore -X (deeratho - E INFOCHIPS PRIVATE LIMITED at Cisco) wrote: > 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
Hi Deepak, Sorry for my late reply. Thank you for analysis and testing the backport. I agree, backporting a complex patch that isn't built in default configuration is not what we want. To answer your question, recipes are maintained and validated based on their default configuration. We do not maintain heavy backports for disabled components. So, even if conditionnal CVE_STATUS is usually not the preferred approach, we'll take your patch as is (but probably in the next round of review). Regards, -- Fabien Thomas Smile ECS
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#243730): https://lists.openembedded.org/g/openembedded-core/message/243730 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]] -=-=-=-=-=-=-=-=-=-=-=-
