On Wed Jul 29, 2026 at 8:33 AM CEST, Ashishkumar Parmar X (asparmar - E INFOCHIPS PRIVATE LIMITED at Cisco) via lists.openembedded.org wrote: > Hello Yoann, > > Thanks for reporting this. > > I tested the complete rsync series in a clean Debian 11 environment. The > rsync-native build passed all 157 tasks without sstate reuse. > > This differs from the Scarthgap issue. Wrynose already includes the upstream > openat2 portability fix as CVE-2026-43619_p6.patch, including the > configure-time checks for <linux/openat2.h> and SYS_openat2. > > The reported Wrynose failure instead occurs during the compiler sanity check, > where the linker rejects the unsupported --no-rosegment option: > > /usr/bin/ld: unrecognized option '--no-rosegment' > > This appears to come from stale or mismatched hosttools/ld state rather than > the rsync patches. > > Could you retry after regenerating hosttools/ld?
You are right, it does build, sorry (my hosttools/ld was not up-to-date). FYI, even if the patch build and passes tests, there are questions in the Yocto community on how to handle these large CVE patches that AI tend to generate. This was discussed at yesterday's "weekly engineering sync" meeting: https://www.yoctoproject.org/community/get-involved/#virtual-meetings The main points that were raised: * The patches size prevent us from reviewing it realistically: A usual (for us) CVE patch is a few lines long. Those are a few thousand! We (as in the Yocto community) might have to decide if we'd rather have a CVE fixed at the risk of stability or ensure stability at the cost of having a few CVEs unfixed. * The patches size force to backport a lot of dependant changes to handle backport conflicts until a point where we backport most of the development branch. And then, what is a point of the stable policy? So, I'll put these patches (wrynose&scarthgap) on hold for now.until we reach a consensus/decision. Regards, > > Regards, > Ashish > ________________________________ > From: Yoann Congal <[email protected]> > Sent: 28 July 2026 18:57 > To: Ashishkumar Parmar -X (asparmar - E INFOCHIPS PRIVATE LIMITED at Cisco) > <[email protected]>; [email protected] > <[email protected]> > Cc: xe-linux-external (Internal Group) <[email protected]> > Subject: Re: [OE-core][wrynose][PATCH v3 1/6] rsync: Fix CVE-2026-29518 > > On Fri Jul 24, 2026 at 6:39 AM CEST, Ashishkumar Parmar X (asparmar - E > INFOCHIPS PRIVATE LIMITED at Cisco) via lists.openembedded.org wrote: >> From: Ashishkumar Parmar <[email protected]> >> >> This patch backports the upstream rsync v3.4.3 security fix train for >> CVE-2026-29518. The direct CVE fixes are [3] and [4]: >> >> - [3] enables secure_relative_open() for daemon modules running with >> "use chroot = no", closing the receiver-side basis-file TOCTOU. >> - [4] routes the sender read path through secure_relative_open() from >> the trusted module root, closing the matching sender-side TOCTOU. >> >> This patch also carries [1] and [2] from the same upstream v3.4.3 >> security/update train. These are supporting secure_relative_open() >> changes, not standalone direct CVE fixes: [1] uses Linux >> openat2(RESOLVE_BENEATH) to preserve the same confinement while allowing >> legitimate in-tree symlinks, fixing upstream issue #715; [2] adds the >> equivalent FreeBSD/macOS O_RESOLVE_BENEATH path. Debian's >> rsync 3.4.1+ds1-5+deb13u3 security update also carries these commits >> before the direct CVE-2026-29518 commits. >> >> The upstream fixed release is referenced in [5], and the public CVE >> record is referenced in [6]. Individual backported commit links are >> also recorded in the embedded patch headers. >> >> [1] >> https://github.com/RsyncProject/rsync/commit/4fa7156ccdb2ad34b034d18fe2fd6cd79adef8a1 >> [2] >> https://github.com/RsyncProject/rsync/commit/7f60ec001a0be63b770707ec8b829524c3809a43 >> [3] >> https://github.com/RsyncProject/rsync/commit/f1c24ab03bc85cb2638a569faa60216582fb6c5d >> [4] >> https://github.com/RsyncProject/rsync/commit/859d44fa4f1420775e4ba050337ef32092f2894c >> [5] https://github.com/RsyncProject/rsync/releases/tag/v3.4.3 >> [6] https://www.cve.org/CVERecord?id=CVE-2026-29518 >> >> Signed-off-by: Ashishkumar Parmar <[email protected]> >> --- >> Changes in v2: >> - No changes made; rebase only. >> >> .../rsync/files/CVE-2026-29518_p1.patch | 392 ++++++++++++++++++ >> .../rsync/files/CVE-2026-29518_p2.patch | 98 +++++ >> .../rsync/files/CVE-2026-29518_p3.patch | 328 +++++++++++++++ >> .../rsync/files/CVE-2026-29518_p4.patch | 71 ++++ >> meta/recipes-devtools/rsync/rsync_3.4.1.bb | 4 + >> 5 files changed, 893 insertions(+) >> create mode 100644 meta/recipes-devtools/rsync/files/CVE-2026-29518_p1.patch >> create mode 100644 meta/recipes-devtools/rsync/files/CVE-2026-29518_p2.patch >> create mode 100644 meta/recipes-devtools/rsync/files/CVE-2026-29518_p3.patch >> create mode 100644 meta/recipes-devtools/rsync/files/CVE-2026-29518_p4.patch > > Hello, > > This series caused a build issue. > See: > https://lore.kernel.org/openembedded-core/[email protected]/T/#mac8cd24d85cb37cd8fa468a51921ac376e238c7f > > Regards, > -- > Yoann Congal > Smile ECS -- Yoann Congal Smile ECS
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#242270): https://lists.openembedded.org/g/openembedded-core/message/242270 Mute This Topic: https://lists.openembedded.org/mt/120421792/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
