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
>
> Tested with ptest:
> Before: PASSED: 5, FAILED: 0, SKIPPED: 0
> After: PASSED: 5, FAILED: 0, SKIPPED: 0
>
> Signed-off-by: Daniel Turull <[email protected]>
> ---
> .../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" <[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):
> +- 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 <[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 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#243507):
https://lists.openembedded.org/g/openembedded-core/message/243507
Mute This Topic: https://lists.openembedded.org/mt/120463656/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
