mirror of
https://github.com/postgres/postgres.git
synced 2026-06-23 00:51:00 -04:00
Michael Paquier
6a67c540a6
pg_rewind and pg_basebackup could be fed paths from rogue endpoints that could overwrite the contents of the client when received, achieving path traversal. There were two areas in the tree that were sensitive to this problem: - pg_basebackup, through the astreamer code, where no validation was performed before building an output path when streaming tar data. This is an issue in v15 and newer versions. - pg_rewind file operations for paths received through libpq, for all the stable branches supported. In order to address this problem, this commit adds a helper function in path.c, that reuses path_is_relative_and_below_cwd() after applying canonicalize_path(). This can be used to validate the paths received from a connection point. A path is considered invalid if any of the two following conditions is satisfied: - The path is absolute. - The path includes a direct parent-directory reference. Reported-by: XlabAI Team of Tencent Xuanwu Lab Reported-by: Valery Gubanov <valerygubanov95@gmail.com> Author: Michael Paquier <michael@paquier.xyz> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Backpatch-through: 14 Security: CVE-2026-6475
src/port/README
libpgport
=========
libpgport must have special behavior. It supplies functions to both
libraries and applications. However, there are two complexities:
1) Libraries need to use object files that are compiled with exactly
the same flags as the library. libpgport might not use the same flags,
so it is necessary to recompile the object files for individual
libraries. This is done by removing -lpgport from the link line:
# Need to recompile any libpgport object files
LIBS := $(filter-out -lpgport, $(LIBS))
and adding infrastructure to recompile the object files:
OBJS= execute.o typename.o descriptor.o data.o error.o prepare.o memory.o \
connect.o misc.o path.o exec.o \
$(filter strlcat.o, $(LIBOBJS))
The problem is that there is no testing of which object files need to be
added, but missing functions usually show up when linking user
applications.
2) For applications, we use -lpgport before -lpq, so the static files
from libpgport are linked first. This avoids having applications
dependent on symbols that are _used_ by libpq, but not intended to be
exported by libpq. libpq's libpgport usage changes over time, so such a
dependency is a problem. Windows, Linux, and macOS use an export
list to control the symbols exported by libpq.