All of lore.kernel.org
 help / color / mirror / Atom feed
* [wrynose][PATCH] libarchive: fix CVE-2026-14164
@ 2026-07-27  7:34 daniel.turull
  2026-08-16  9:32 ` Paul Barker
  0 siblings, 1 reply; 3+ messages in thread
From: daniel.turull @ 2026-07-27  7:34 UTC (permalink / raw)
  To: openembedded-core; +Cc: Daniel Turull

From: Daniel Turull <daniel.turull@ericsson.com>

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

Tested with ptest:
Before: PASSED: 5, FAILED: 0, SKIPPED: 0
After: PASSED: 5, FAILED: 0, SKIPPED: 0

Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
---
 .../libarchive/CVE-2026-14164.patch           | 53 +++++++++++++++++++
 .../libarchive/libarchive_3.8.7.bb            |  1 +
 2 files changed, 54 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 0000000000..b734fc448f
--- /dev/null
+++ b/meta/recipes-extended/libarchive/libarchive/CVE-2026-14164.patch
@@ -0,0 +1,53 @@
+From edbac77e8e544286fe7581bc398781c949ee5a22 Mon Sep 17 00:00:00 2001
+From: "Dustin L. Howett" <dustin@howett.net>
+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):
+- The stable branch's init_unpack() already unconditionally NULLs
+  rar->cstate.window_buf and rar->cstate.filtered_buf right after free()
+  (the core CVE fix), but still retained the redundant else-branch that
+  re-NULLed them when window_size <= 0. Removed that dead else-branch to
+  match the upstream fix, and omitted upstream's added
+  `if(...== NULL) return ARCHIVE_FATAL;` calloc failure checks, since
+  init_unpack() is void-returning in this stable version and predates
+  that hardening.
+
+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 <daniel.turull@ericsson.com>
+---
+ 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 63dd97b3..271aa0cb 100644
+--- a/libarchive/archive_read_support_format_rar5.c
++++ b/libarchive/archive_read_support_format_rar5.c
+@@ -2568,12 +2568,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);
diff --git a/meta/recipes-extended/libarchive/libarchive_3.8.7.bb b/meta/recipes-extended/libarchive/libarchive_3.8.7.bb
index e8c3a3bfe3..ecb13a6772 100644
--- a/meta/recipes-extended/libarchive/libarchive_3.8.7.bb
+++ b/meta/recipes-extended/libarchive/libarchive_3.8.7.bb
@@ -31,6 +31,7 @@ EXTRA_OECONF += "--enable-largefile --without-iconv"
 
 SRC_URI = "https://libarchive.org/downloads/libarchive-${PV}.tar.gz \
            file://run-ptest \
+           file://CVE-2026-14164.patch \
           "
 UPSTREAM_CHECK_URI = "https://www.libarchive.org/"
 


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [wrynose][PATCH] libarchive: fix CVE-2026-14164
  2026-07-27  7:34 [wrynose][PATCH] libarchive: fix CVE-2026-14164 daniel.turull
@ 2026-08-16  9:32 ` Paul Barker
  2026-08-17  7:41   ` Daniel Turull
  0 siblings, 1 reply; 3+ messages in thread
From: Paul Barker @ 2026-08-16  9:32 UTC (permalink / raw)
  To: daniel.turull, openembedded-core

On Mon, 2026-07-27 at 09:34 +0200, daniel.turull@ericsson.com wrote:
> From: Daniel Turull <daniel.turull@ericsson.com>
> 
> 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
> 
> Tested with ptest:
> Before: PASSED: 5, FAILED: 0, SKIPPED: 0
> After: PASSED: 5, FAILED: 0, SKIPPED: 0
> 
> Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
> ---
>  .../libarchive/CVE-2026-14164.patch           | 53 +++++++++++++++++++
>  .../libarchive/libarchive_3.8.7.bb            |  1 +
>  2 files changed, 54 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 0000000000..b734fc448f
> --- /dev/null
> +++ b/meta/recipes-extended/libarchive/libarchive/CVE-2026-14164.patch
> @@ -0,0 +1,53 @@
> +From edbac77e8e544286fe7581bc398781c949ee5a22 Mon Sep 17 00:00:00 2001
> +From: "Dustin L. Howett" <dustin@howett.net>
> +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):
> +- The stable branch's init_unpack() already unconditionally NULLs
> +  rar->cstate.window_buf and rar->cstate.filtered_buf right after free()
> +  (the core CVE fix), but still retained the redundant else-branch that
> +  re-NULLed them when window_size <= 0. Removed that dead else-branch to
> +  match the upstream fix, and omitted upstream's added
> +  `if(...== NULL) return ARCHIVE_FATAL;` calloc failure checks, since
> +  init_unpack() is void-returning in this stable version and predates
> +  that hardening.
> +
> +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 <daniel.turull@ericsson.com>
> +---
> + 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 63dd97b3..271aa0cb 100644
> +--- a/libarchive/archive_read_support_format_rar5.c
> ++++ b/libarchive/archive_read_support_format_rar5.c
> +@@ -2568,12 +2568,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);

Hi Daniel,

The above fix didn't make sense to me, so I looked in to the CVE. The
initial report [1] says:

    The issue occurs when parsing a valid RAR5 archive that exercises
    the filter path. During decompression, rar->cstate.filtered_buf can
    be assigned to a filter output buffer. Later, when libarchive
    processes a subsequent file and reinitializes the unpacking state,
    init_unpack() frees the existing filtered_buf but does not clear the
    pointer.

    If the following allocation fails, init_unpack() returns
    ARCHIVE_FATAL while rar->cstate.filtered_buf still contains a
    dangling pointer. When the caller later releases the archive object,
    rar5_cleanup() frees the same pointer again, resulting in a
    double-free.

[1]: https://github.com/libarchive/libarchive/issues/3069

The `return ARCHIVE_FATAL` paths are not present in libarchive 3.8.7, so
the function can't return between while rar->cstate.filtered_buf is
still a dangling pointer.

Let me know if you agree with that analysis, if so then perhaps we can
handle this via CVE_STATUS.

Best regards,

-- 
Paul Barker



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [wrynose][PATCH] libarchive: fix CVE-2026-14164
  2026-08-16  9:32 ` Paul Barker
@ 2026-08-17  7:41   ` Daniel Turull
  0 siblings, 0 replies; 3+ messages in thread
From: Daniel Turull @ 2026-08-17  7:41 UTC (permalink / raw)
  To: openembedded-core@lists.openembedded.org, paul@pbarker.dev

On Sun, 2026-08-16 at 10:32 +0100, Paul Barker wrote:
> On Mon, 2026-07-27 at 09:34 +0200, daniel.turull@ericsson.com wrote:
> > From: Daniel Turull <daniel.turull@ericsson.com>
> >
> > 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
> >
> > Tested with ptest:
> > Before: PASSED: 5, FAILED: 0, SKIPPED: 0
> > After: PASSED: 5, FAILED: 0, SKIPPED: 0
> >
> > Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
> > ---
> >  .../libarchive/CVE-2026-14164.patch           | 53 +++++++++++++++++++
> >  .../libarchive/libarchive_3.8.7.bb            |  1 +
> >  2 files changed, 54 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 0000000000..b734fc448f
> > --- /dev/null
> > +++ b/meta/recipes-extended/libarchive/libarchive/CVE-2026-14164.patch
> > @@ -0,0 +1,53 @@
> > +From edbac77e8e544286fe7581bc398781c949ee5a22 Mon Sep 17 00:00:00 2001
> > +From: "Dustin L. Howett" <dustin@howett.net>
> > +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):
> > +- The stable branch's init_unpack() already unconditionally NULLs
> > +  rar->cstate.window_buf and rar->cstate.filtered_buf right after free()
> > +  (the core CVE fix), but still retained the redundant else-branch that
> > +  re-NULLed them when window_size <= 0. Removed that dead else-branch to
> > +  match the upstream fix, and omitted upstream's added
> > +  `if(...== NULL) return ARCHIVE_FATAL;` calloc failure checks, since
> > +  init_unpack() is void-returning in this stable version and predates
> > +  that hardening.
> > +
> > +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/lib
> > archive%2Fcommit%2Ff774f03b40cb109348e5c6d52b59c864e3cfa8e8&data=05%7C02%7Cdaniel.turull%40erics
> > son.com%7C8fb93b3eadb44ed7b3dd08defb795ae2%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C63922469
> > 5802503711%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI
> > kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=U8k1wVVScu7YauxaGlz9h40KSnrjx7%2F1HbKc76cYj7U
> > %3D&reserved=0]
> > +
> > +Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
> > +---
> > + 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 63dd97b3..271aa0cb 100644
> > +--- a/libarchive/archive_read_support_format_rar5.c
> > ++++ b/libarchive/archive_read_support_format_rar5.c
> > +@@ -2568,12 +2568,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);
>
> Hi Daniel,
>
> The above fix didn't make sense to me, so I looked in to the CVE. The
> initial report [1] says:
>
>     The issue occurs when parsing a valid RAR5 archive that exercises
>     the filter path. During decompression, rar->cstate.filtered_buf can
>     be assigned to a filter output buffer. Later, when libarchive
>     processes a subsequent file and reinitializes the unpacking state,
>     init_unpack() frees the existing filtered_buf but does not clear the
>     pointer.
>
>     If the following allocation fails, init_unpack() returns
>     ARCHIVE_FATAL while rar->cstate.filtered_buf still contains a
>     dangling pointer. When the caller later releases the archive object,
>     rar5_cleanup() frees the same pointer again, resulting in a
>     double-free.
>
> [1]:
> https://github.com/libarchive/libarchive/issues/3069
>
> The `return ARCHIVE_FATAL` paths are not present in libarchive 3.8.7, so
> the function can't return between while rar->cstate.filtered_buf is
> still a dangling pointer.
>
> Let me know if you agree with that analysis, if so then perhaps we can
> handle this via CVE_STATUS.

I agree with your analysis. I was just focused that the backport was similar at the patch pointed in
the CVE information. I'll send a v2 with CVE_STATUS fixed-version with your reasoning for both
scarthgap and wrynose

Thanks
Daniel
>
> Best regards,
>


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-08-17  7:41 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-27  7:34 [wrynose][PATCH] libarchive: fix CVE-2026-14164 daniel.turull
2026-08-16  9:32 ` Paul Barker
2026-08-17  7:41   ` Daniel Turull

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.