On Wed Jul 29, 2026 at 12:27 PM CEST, Yoann Congal wrote:
> 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.
Hello,
I'm sorry but we ultimately decided to reject this series. See the
updated doc[0][1] for rational:
> Patches submitted for a stable branch need to be isolated changes that
> are human readable and understandable. Fixes for CVEs or other issues
> which have a high complexity, consist of a large number of commits
> and/or a large numbers of changed lines are unlikely to be accepted due
> to the difficulty they cause with maintainability and scalability.
[0]: 4 Contributing Changes to a Component — The Yocto Project ® dev
documentation
https://docs.yoctoproject.org/dev/contributor-guide/submit-changes.html#submitting-changes-to-stable-release-branches
[1]: contributor-guide: Note patch complexity requirements for stable branches
- yocto-docs - Versioned project documentation
https://git.yoctoproject.org/yocto-docs/commit/?id=33bf0ff80df6be2aad8eb081752648d3c408a54b
Regards,
>
> 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 (#244211):
https://lists.openembedded.org/g/openembedded-core/message/244211
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]]
-=-=-=-=-=-=-=-=-=-=-=-
