libarchive 3.8.8 (CVE-2026-14164)

[laffer1]

Update libarchive from 3.8.7 to 3.8.8.

libarchive 3.8.8 fixes CVE-2026-14164, a high-severity double-free in the
RAR5 reader (archive_read_support_format_rar5.c) that could crash
applications parsing a crafted RAR5 archive (CVSS 7.5, network/DoS).

Changes

• Vendor import of libarchive 3.8.8 on vendor/libarchive/dist (annotated tag
  vendor/libarchive/dist/3.8.8), merged into contrib/libarchive via subtree
  merge.
• Local iconv patch preserved through the merge (ICONV_SET_ILSEQ_INVALID
  extended to __MidnightBSD__ in archive_string.c).
• Backport upstream's own post-3.8.8 fixes for MidnightBSD's strict build flags
  (-Werror -Wwrite-strings -Wcast-qual): const-correct parse_option() in
  archive_options.c, and the new Windows-attribute fflags[] mapping in the
  7zip and RAR5 readers. No functional change.
• UPDATING note added.

No build-glue (Makefile) changes were needed: the new
libarchive_fe/lafe_fnmatch.c is compiled only when HAVE_FNMATCH is
undefined, and MidnightBSD has native fnmatch(3).

Testing

Targeted make buildenv build of lib/libarchive and
bsdtar/bsdcpio/bsdunzip/bsdcat — all compile and link cleanly on
amd64. Ran a tar create/list/extract round-trip and a bsdunzip pattern
extraction against the freshly built 3.8.8 library; the library reports
libarchive 3.8.8.

Security: CVE-2026-14164
AI-Assisted-by: Claude Opus 4.8

[sourcery-ai]

Sorry, we are unable to review this pull request

The GitHub API does not allow us to fetch diffs exceeding 300 files, and this pull request has 332

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of files (300). Try reducing the number of changed files and requesting a review from Copilot again.

[github-actions]

Claude finished @laffer1's task in 1m 43s —— View job

---

Claude's Task List

• Gather context (PR body, changed files, custom review instructions)
• Review local/non-vendor changes (UPDATING, iconv patch, const-correctness backports)
• Spot-check vendor diff for anything MidnightBSD-specific vs. pure upstream sync
• Check for assembly / contrib/mksh changes (prohibited for AI review)
• Post review feedback

Review Summary

No assembly or contrib/mksh files are touched by this PR, so no AI-review restrictions apply. The bulk of the diff (~43k lines) is an upstream vendor sync of libarchive 3.8.8, already reviewed/released upstream — I focused verification on the MidnightBSD-local pieces called out in the PR description.

UPDATING (UPDATING:4-9) — entry is well-formed, dated 20260722 consistent with the surrounding log, correctly references CVE-2026-14164 and the affected file.

archive_string.c — confirmed the ICONV_SET_ILSEQ_INVALID/__MidnightBSD__ block (archive_string.c:1317-1326) is untouched by this diff, so the local iconv patch survived the merge intact. The one hunk that did change is upstream's own Windows WINAPI_FAMILY_PARTITION macro guard — unrelated to MidnightBSD.

archive_options.c const-correctness backport — parse_option() now takes/returns char * instead of casting away const, and _archive_set_options() mirrors the type change (s is now char *, mod/opt/val stay const char *). Traced all assignments (mod = opt, *o = opt) — all are non-const → const, which is safe. No functional change, matches the PR description.

7zip/RAR5 fflags[] backport (archive_read_support_format_7zip.c:1036-1050, archive_read_support_format_rar5.c:1951-1966) — replaces a malloc(22) + manual strcpy/pointer-walk with a fixed char buf[sizeof(",rdonly,hidden,system")] (23 bytes) + snprintf. Verified the max concatenation (",rdonly"+",hidden"+",system" = 21 chars + NUL = 22) fits within the 23-byte buffer with room to spare, and the outer if (attr & supported_attrs) guard guarantees at least one flag is set before buf + 1 is dereferenced. Correctly bounded, no malloc/free asymmetry risk.

Core CVE fix — init_unpack() in archive_read_support_format_rar5.c (init_unpack diff hunk) now nulls rar->cstate.window_buf/filtered_buf immediately after free(), before the subsequent calloc() calls that can fail, and returns int/ARCHIVE_FATAL on allocation failure instead of silently leaving stale pointers. Callers now check the return value before proceeding (archive_read_support_format_rar5.c:519-520). This is the correct fix pattern for the double-free — a failed calloc after the first free() can no longer leave a dangling pointer for a later cleanup path to double-free.

No correctness, malloc/free symmetry, bounds-checking, or security issues found in the reviewed hunks. The remainder of the vendor sync (filters, tar/zip/iso9660/cab/lha/xar readers, etc.) is upstream-authored and upstream-tested; a full line-by-line audit of all 43k changed lines is outside the scope of a targeted CVE-backport review, and Sourcery/Copilot both declined to review due to the 300+ file diff size.

One minor observation (non-blocking): the vendor code uses upstream's own K&R-ish brace/spacing conventions rather than style(9) — this is expected and consistent with how contrib/ is normally handled (vendor code is not reformatted to local style).