On Mon, 2026-07-27 at 09:34 +0200, [email protected] wrote: > From: Daniel Turull <[email protected]> > > Backport patch to fix CVE-2026-14164. > > References: > https://nvd.nist.gov/vuln/detail/CVE-2026-14164 > > Upstream fix: > > https://github.com/libarchive/libarchive/commit/f774f03b40cb109348e5c6d52b59c864e3cfa8e8 > > Signed-off-by: Daniel Turull <[email protected]> > --- > .../libarchive/CVE-2026-14164.patch | 52 +++++++++++++++++++ > .../libarchive/libarchive_3.7.9.bb | 1 + > 2 files changed, 53 insertions(+) > create mode 100644 > meta/recipes-extended/libarchive/libarchive/CVE-2026-14164.patch > > diff --git a/meta/recipes-extended/libarchive/libarchive/CVE-2026-14164.patch > b/meta/recipes-extended/libarchive/libarchive/CVE-2026-14164.patch > new file mode 100644 > index 00000000000..c94764acf29 > --- /dev/null > +++ b/meta/recipes-extended/libarchive/libarchive/CVE-2026-14164.patch > @@ -0,0 +1,52 @@ > +From 5efdd23ea2569314d62492bdc0b078f4dad1f75a Mon Sep 17 00:00:00 2001 > +From: "Dustin L. Howett" <[email protected]> > +Date: Sun, 24 May 2026 12:43:00 -0500 > +Subject: [PATCH] Merge pull request #3071 from stoeckmann/rar5_doublefree > + > +rar5: Avoid dangling pointers in init_unpack > +(cherry picked from commit 42453cf16255800726b4efedab25138639ceef20) > + > +Conflicts Resolved: > + > +libarchive/archive_read_support_format_rar5.c (1 conflict): > +- Stable's init_unpack() is a void function without the calloc failure > + checks (`if(...== NULL) return ARCHIVE_FATAL;`) that exist upstream, > + since it predates that hardening. Kept the CVE fix logic (unconditionally > + setting rar->cstate.window_buf and rar->cstate.filtered_buf to NULL right > + after free(), and removing the redundant else-branch that only NULLed > + them when window_size <= 0) and omitted the ARCHIVE_FATAL return checks, > + which don't apply to this void-returning stable version. > + > +Assisted-by: kiro:claude-sonnet-5 > + > +Changes from upstream commit f774f03b40cb: > + - libarchive/archive_read_support_format_rar5.c: adapted from upstream > + > +CVE: CVE-2026-14164 > +Upstream-Status: Backport > [https://github.com/libarchive/libarchive/commit/f774f03b40cb109348e5c6d52b59c864e3cfa8e8] > + > +Signed-off-by: Daniel Turull <[email protected]> > +--- > + libarchive/archive_read_support_format_rar5.c | 6 +++--- > + 1 file changed, 3 insertions(+), 3 deletions(-) > + > +diff --git a/libarchive/archive_read_support_format_rar5.c > b/libarchive/archive_read_support_format_rar5.c > +index 736c95a6..098cd6f7 100644 > +--- a/libarchive/archive_read_support_format_rar5.c > ++++ b/libarchive/archive_read_support_format_rar5.c > +@@ -2489,12 +2489,12 @@ static void init_unpack(struct rar5* rar) { > + free(rar->cstate.window_buf); > + free(rar->cstate.filtered_buf); > + > ++ rar->cstate.window_buf = NULL; > ++ rar->cstate.filtered_buf = NULL; > ++ > + if(rar->cstate.window_size > 0) { > + rar->cstate.window_buf = calloc(1, rar->cstate.window_size); > + rar->cstate.filtered_buf = calloc(1, rar->cstate.window_size); > +- } else { > +- rar->cstate.window_buf = NULL; > +- rar->cstate.filtered_buf = NULL; > + } > + > + clear_data_ready_stack(rar);
Same comment here as I made on the wrynose patch [1]. [1]: https://lore.kernel.org/openembedded-core/[email protected]/ The `return ARCHIVE_FATAL` paths are not present in libarchive 3.7.9, so the function can't return between while rar->cstate.filtered_buf is still a dangling pointer. Best regards, -- Paul Barker
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#243508): https://lists.openembedded.org/g/openembedded-core/message/243508 Mute This Topic: https://lists.openembedded.org/mt/120463657/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
