April 2026 - Pacman-dev - lists.archlinux.org

[RFC] libalpm: validate archive entry paths in extract_single_file
by Strykar 15 Apr '26

15 Apr '26

Hi all, I'd like to introduce a small hardening change (found by Claude) in lib/libalpm/add.c and get upstream's take before sending an MR. Branch (2 signed commits, rebased on current master): https://gitlab.archlinux.org/strykar/pacman/-/tree/harden/extract-entry-val… perform_extraction() passes ARCHIVE_EXTRACT_OWNER | PERM | TIME | UNLINK | XATTR | SECURE_SYMLINKS to libarchive (add.c:118) — no SECURE_NODOTDOT, no SECURE_NOABSOLUTEPATHS. extract_single_file then builds the on-disk path as snprintf("%s%s", handle->root, entryname) (add.c:216) from the archive's entryname and overrides the entry pathname via archive_entry_set_pathname. An entryname with a leading /, or one whose .. components leave handle->root after concatenation (e.g. foo/../../etc/evil), extracts outside handle->root. One accidental mitigation to note: entries starting with . route to extract_db_file, which silently drops anything other than .INSTALL/.MTREE/.CHANGELOG (add.c:204-208). So a literal ../etc/x is a no-op today — the practical exploit requires either a non-dot-prefixed traversal (foo/../../etc/x) or a leading /. The alpm_filelist_contains gate at add.c:208 does not provide independent validation: per be_package.c:612-618, newpkg->files is populated from the archive's own .MTREE (preferred) or from the tar entries as fallback. In the unsigned / -U / SigLevel = TrustAll case, both sources are attacker-controlled in a tampered archive, so a malicious builder lists the traversal path in .MTREE and ships the matching tar entry — the check passes. Signed repo install: package is trusted, .INSTALL runs as root, traversal adds nothing. Not trying to escalate this. Where the gap matters. pacman -U on locally-built or SigLevel = TrustAll packages; --root for staging / image builds / pacstrap-like flows (the 2024 Trail of Bits audit, Recommendations p.7, notes --root does not guarantee files outside the root remain untouched); non-root libalpm consumers. Why libarchive flags alone don't cut it. Adding SECURE_NOABSOLUTEPATHS to archive_flags rejects every entry, because pacman itself sets the entry pathname to handle->root + entryname, which is absolute. SECURE_NODOTDOT would catch middle-.. cases (the concat is a dumb snprintf, not normalizing, so .. survives in the final path) but not a leading / in the entry (concat yields //etc/foo, which has no ..). So any fix needs a lexical check on the raw entryname anyway. I dropped SECURE_NODOTDOT as redundant; happy to add it as belt-and-braces if reviewers prefer. Proposed change. A small lexical validator on archive_entry_pathname and archive_entry_hardlink, called before alpm_filelist_contains. Reject on leading /, empty/NULL, or any .. path component. On reject: log and abort the install. Build/test. Builds clean on master. Full meson test passes: 341 OK, 6 pre-existing ExpectedFail, 0 failures — including three new tests covering foo/../../etc/evil (rejected), /etc/evil (rejected), and usr/share/foo..bar/baz (accepted, false-positive guard). Tests assert PACMAN_RETCODE=1 and !FILE_EXIST=etc/evil. One minor test-infra addition: an allow_unsafe_paths flag on pmpkg so absolute-path entries can be authored into a test archive (pmpkg.py:201 refuses them by default). Empirical check. Scanned every file entry in the synced core/extra/multilib/aurpkgs file databases on my machine — 7,712,742 entries, zero with leading / or .. components. The list will have broader visibility than I do; I'd welcome counter-examples from cross / dev-kit packaging in particular. Open questions: Abort vs skip-and-warn? I lean abort: presence is evidence of tampering or a broken build tool. Any legitimate case in Arch packaging where a tar entry has .. or leading /? Follow-up patch to extend to extract_db_file for symmetry? Interest in also enabling SECURE_NODOTDOT as defense-in-depth alongside the lexical check? Orthogonal observation worth a separate thread: when -U extraction fails mid-transaction, the package is left registered in the local db (discovered while writing these tests — not caused by this patch). Happy to file separately. Not framing this as a vulnerability — the declared trust model covers default installs. But the --root / unsigned--U / non-root-consumer gap is the shape of thing the ToB audit flagged as under-specified, and this is ~20 lines that closes it. Commits are signed with key E4A8486E91D492EA. Please let me know if an MR is preferred over this RFC flow or is this a umad / wontfix trustmodel? Thanks, Strykar

2 2

[PATCH] conf: Fix off-by-one heap overrun in escape_chars()
by Chris Down 14 Apr '26

14 Apr '26

escape_chars() computes the post-escaping buffer size as len + pattern_chars, but unfortunately never accounts for the null terminator it unconditionally writes afterwards. That means that when pacman-conf applies --sysroot to an Include directive and that sysroot path contains a character that also happens to be a glob metacharacter, the null terminator is written one byte past the end of the allocation. Fix both the overflow guard and the malloc size so the terminator always falls within the allocated region. The off by one write is reliably caught by ASAN, so add a dedicated TAP test to prevent regressions. Fixes: 7016adcb7035 ("manually apply --sysroot to configuration") --- meson.build | 2 +- src/pacman/conf.c | 4 +-- test/util/meson.build | 9 +++++ test/util/pacman-conf-sysroot-escape.sh | 45 +++++++++++++++++++++++++ 4 files changed, 57 insertions(+), 3 deletions(-) create mode 100755 test/util/pacman-conf-sysroot-escape.sh diff --git a/meson.build b/meson.build index 8e2444d1..800f37e9 100644 --- a/meson.build +++ b/meson.build @@ -374,7 +374,7 @@ pacman_bin = executable( install : true, ) -executable( +pacman_conf_bin = executable( 'pacman-conf', pacman_conf_sources, include_directories : includes, diff --git a/src/pacman/conf.c b/src/pacman/conf.c index e391735a..fd419529 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -1132,8 +1132,8 @@ static char *escape_chars(const char *pattern, const char *escape) } /* allocate new string with overflow check */ - if(SIZE_MAX - len < pattern_chars - || !(escaped = malloc(len + pattern_chars))) { + if(SIZE_MAX - len <= pattern_chars + || !(escaped = malloc(len + pattern_chars + 1))) { errno = ENOMEM; return NULL; } diff --git a/test/util/meson.build b/test/util/meson.build index b4046298..71921296 100644 --- a/test/util/meson.build +++ b/test/util/meson.build @@ -5,3 +5,12 @@ test('vercmptest', args : [ join_paths(meson.current_source_dir(), 'vercmptest.sh') ]) + +test('pacman-conf-sysroot-escape', + BASH, + env : TEST_ENV, + protocol : 'tap', + args : [ + join_paths(meson.current_source_dir(), 'pacman-conf-sysroot-escape.sh') + ], + depends : [pacman_conf_bin]) diff --git a/test/util/pacman-conf-sysroot-escape.sh b/test/util/pacman-conf-sysroot-escape.sh new file mode 100755 index 00000000..473c369d --- /dev/null +++ b/test/util/pacman-conf-sysroot-escape.sh @@ -0,0 +1,45 @@ +#!/bin/bash +# +# pacman-conf-sysroot-escape - verify sysroot glob escaping under ASAN +# +# Copyright (c) 2026 Pacman Development Team <pacman-dev(a)lists.archlinux.org> +# +# This program is free software; you can redistribute it and/or modify it under +# the terms of the GNU General Public License as published by the Free Software +# Foundation; either version 2 of the License, or (at your option) any later +# version. +# +# This program is distributed in the hope that it will be useful, but WITHOUT +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS +# FOR A PARTICULAR PURPOSE. See the GNU General Public License for more +# details. +# +# You should have received a copy of the GNU General Public License along with +# this program. If not, see <http://www.gnu.org/licenses/>. + +source "$(dirname "$0")"/../tap.sh || exit 1 + +bin=${1:-${PMTEST_UTIL_DIR}pacman-conf} + +if ! type -p "$bin" &>/dev/null; then + tap_bail "pacman-conf binary ($bin) could not be located" + exit 1 +fi + +tmpdir=$(mktemp -d) +trap 'rm -rf "$tmpdir"' EXIT + +sysroot="$tmpdir/sys[root" +mkdir -p "$sysroot/etc" "$sysroot/dev" +: > "$sysroot/dev/null" +printf '[options]\nInclude = /dev/null\n' > "$sysroot/etc/pacman.conf" + +tap_plan 2 + +output=$("$bin" --sysroot "$sysroot" --config /etc/pacman.conf RootDir 2>&1) +ret=$? + +tap_is_int "$ret" 0 "pacman-conf parses Include under metachar sysroot" +tap_is_str "$output" "$sysroot/" "pacman-conf preserves the escaped sysroot" + +tap_finish base-commit: a6f7467d8c7c4d7e9cc846884e74c0ab7215c48d -- 2.53.0

2 3

[RFC] Proposal: 1-byte status signaling for db.lck
by Carsten Heine 05 Apr '26

05 Apr '26

Hello, I am proposing a specification update for the ALPM/Pacman lock file. The current binary-existential state (exists/not exists) is insufficient for modern multi-process environments and leads to significant state-blindness for administrators. Specification: # Feature-Request: Content-Based Lock-State Signaling (CBLSS) Author: Carsten Udo Heine <cuheine(a)gmail.com> Version: 20260404-1316 Abstract: The current db.lck mechanism in ALPM/Pacman is purely binary. This proposal introduces a 1-byte status register (Hex-Nibbles) and vector-based logging (New (Old)) to ensure transparency. Rationale: 1. Context Awareness: Allows admins to distinguish between critical mutations (Writing) and non-invasive tasks (Pending/Info). 2. Deterministic Forensics: The New (Old) notation (e.g., 01 (30)) documents transitions. Missing transitions reveal crashes. 3. Architectural Discipline: Forces UI wrappers to justify their state, exposing preemptive locking "overcast". Technical Specification (The "Hex-Nipple" Model): The file /var/lib/pacman/db.lck shall contain exactly 1 Byte. High Nipple (Soft/Info) : Low Nipple (Hart/Action) : Definition 0 0 doneOK: System is free. 1 0 Pending: Background update check in progress. 2 0 Information: Updates found; no active mutation. 3 0 Waiting: GUI awaiting user input (Block risk!). 0 1 Writing: CRITICAL. Database mutation in progress. 0 3 Error: Process aborted; potential inconsistency. Logging Protocol (db.lck.log): Format: TIMESTAMP | PID | PROCESS | NEW (OLD) Principle: Append-only. This proposal maintains DRY principles and POSIX integrity without adding new dependencies or daemons. I am looking forward to technical feedback. Regards, Carsten

2 1