| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
The 'edge' stuff seems gone.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
| |
On 32-bit platforms, mmap() larger than 2GB may fail.
This patch ensures that the correct size is printed and provides
parity with commit 90a0c6affc9b2fe9ebd6ba3cf3ee9fbcc1fc5835.
Signed-off-by: Zach van Rijn <me@zv.io>
Closes: https://github.com/gentoo/pax-utils/pull/18
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
At some point the compiler changed to not propagate argument attributes
from the prototype to the definition. Add a hacky macro to insert it
by default instead to avoid need for (void) casts.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
(cherry picked from commit 6508649486444d20636d1ff15df7db7302f3c46c)
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
| |
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
(cherry picked from commit 047684a7cd651f889dd4bad41d95a8feb5717815)
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
| |
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
(cherry picked from commit 4bfa4576e7b64b16937f71094641ec0f39ee47c7)
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
| |
The note name is supposed to be NUL terminated, but if it's not,
make sure we don't keep reading data until we hit out of bounds
by limiting to exactly the number of bytes declared (and that we
already verified fit within valid memory).
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
(cherry picked from commit c7d34ad6cf90f3cbb2a184050996d37966fe2ef1)
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
Make sure the entire structure fits within the bounds of memory,
not just the start of it.
Bug: https://bugs.gentoo.org/922906
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
(cherry picked from commit a5298c41c27a35a5c2dcca0723c808029d241953)
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
We were checking the pointer before dumping it, but missed the
DT_NULL check in the overall while loop.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
(cherry picked from commit 7b37c40d0409d79a925b71135e9de96343096ce8)
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Debian bullseye ships with meson 0.56.2 which is too old to understand
replace().
Work around that with split() and string concatenation.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
Closes: https://github.com/gentoo/pax-utils/pull/16
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
| |
Every cap_t needs to be free'd by calling cap_free() which does a NULL
pointer test itself so callers don't need to.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
| |
Add a basic test that simply makes sure pspax executes just fine, i.e.
doesn't get killed by the seccomp policy.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At least Debian's glibc tries to make use of nscd by default leading to
the getpwuid() / getpwnam() calls in pspax trying to open up a local
connection to /var/run/nscd/socket. Neither socket() nor connect() are
allowed by the seccomp policy, leading to unavoidable killing of the
process:
$ pspax
USER PID PAX MAPS ETYPE NAME CAPS ATTR
Bad system call (core dumped)
$ strace pspax |& tail -3
newfstatat(4, "stat", {st_mode=S_IFREG|0444, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 41
+++ killed by SIGSYS (core dumped) +++
Fix this by making socket() fail with -ENOSYS instead:
$ strace -e trace=socket ./build/pspax >/dev/null
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 ENOSYS (Function not implemented)
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 ENOSYS (Function not implemented)
+++ exited with 0 +++
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
|
|
|
|
|
|
|
| |
Resolves a link failure with -Wl,--as-needed.
Thanks to Mathias Krause for noticing the problem.
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
|
|
|
|
|
|
|
| |
muon doesn't support --print-errorlogs so just use -v which both muon and
meson support.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
| |
While gcc defines __SANITIZE_ADDRESS__, clang requires more verbose
tests. Add them to make the cleanup/security logic work correctly.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
| |
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
| |
There's nothing useful we can parse out of these, so skip them.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
| |
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
Make sure we use the right offset, and make sure the numbers to check
don't overflow themselves -- if nbuckets & nchains are 32-bit, and if
we multiply them by 4, we can easily overflow before we get a chance
to see if they will fit within the memory range.
Bug: https://bugs.gentoo.org/890028
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If alloca allocates too much stack space, program behavior is undefined,
and basically we segfault. There is no way to check whether this will
happen ahead of time, so our only choice is to switch to malloc. If we
try to allocate too much memory from the heap, we'll get a NULL pointer,
and we can diagnose & exit ourselves. Kind of sucks as alloca was a
perfect fit here, but since the size is coming directly from user input,
we can't trust it is always "reasonable".
Bug: https://bugs.gentoo.org/890579
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
| |
Check the extended filename offset doesn't exceed the size of the
extended filename section.
Bug: https://bugs.gentoo.org/890579
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The atoi helper handles signed 32-bit integers, and expects the input
strings to be NUL terminated. Some of the fields are larger than what
signed 32-bit can handle, and none of them are NUL terminated. The
code currently works because it stops processing once it reaches text
that is not numeric, and the content that follows each field is always
non-numeric (e.g. a space).
Add a helper function that leverages strtoll as all of the fields can
fit into a signed 64-bit number. If the number is invalid, flag it as
such, and normalize it to 0 so the rest of the code can continue on.
Bug: https://bugs.gentoo.org/890577
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
| |
The scanelf --help output is the best & most flexible, so move that
to common code so the rest of the tools can benefit from it.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
| |
This avoids limiting buffers to BUFSIZ which is a stdio.h define for
stdio buffers, not for random files, and is not a guaranteed size.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
| |
If these functions weren't able to read data from the files, they'd
return the previous buffer contents which would be pretty confusing.
Fix it to return NULL instead like other get helpers in here.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current scanf format tries to use "%s.1023" to limit reading to 1023
bytes, but that doesn't actually work -- the maximum field width is between
the "%" and the "s", so it should have been "%1023s". This ends up working
anyways because the %s stops reading when it hits NUL or a space. Normally
cmdline is NUL delimited which means argv[0] would have to be 1024+ bytes
inorder to overflow this. Or the process rewrote its cmdline settings such
that argv[0] was that long. Certainly possible, but extremely unlikely.
Fix the scanf string to properly limit to 1023 bytes (+1 for the NUL).
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
| |
Switch to the common helper we have in paxinc already that does
exactly the same thing as this proc_fopen.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current scanf format tries to use "%s.16" to limit reading to 16
bytes, but that doesn't actually work -- the maximum field width is
between the "%" and the "s", so it should have been "%16s". This ends
up working anyways because the %s consumes the entire string before it
stops, and then scanf stops processing after it can't match ".16". If
the size of the field were BUFSIZE or larger, then it'd overflow. In
practice, BUFSIZ tends to be "large" (i.e. O(KiB)), and the kernel will
truncate this field to 16 bytes for userspace programs. Kernel threads
can have longer names, but not that big. At least, on Linux.
Fix the scanf string to properly limit to 15 bytes, and change the local
buffer to be exactly 16 bytes rather than the unrelated BUFSIZ (which is
a stdio.h buffer size, and nothing related to kernel processes). Then
add some more comments to explain what the code is actually doing, and
simplify the final NUL logic to avoid redundant work.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
Use the more standard HAVE_xxx convention, and only define when
available. This avoids further confusion with code that is using
"#ifdef" already.
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
| |
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
| |
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
| |
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
The out-of-tree patches for -fbounds-checking in GCC were great, but
they haven't been updated since the gcc-4.0 days, and the sanitizer
options have made it obsolete, so it's unlikely we'll ever use this
code again.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
| |
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
| |
The same settings, but we have a single file for all our configs now.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
| |
This should help stabilize the tool behavior for different developers.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
| |
We aren't using Python 3.6 anywhere anymore that I care about, so
raise the min version to 3.8. Tools are dropping support for it
too which makes it difficult to reasonably support.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
| |
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
| |
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
| |
We don't have types for these imports, so ignore errors on them.
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
| |
Since pyelftools isn't commonly installed, disable the pylint check
by default.
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
| |
Support for list[...] is new to Python 3.9. We still support Python
3.6 (or at least, 3.8) so we need to use List[...] instead.
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
| |
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
| |
The builder doesn't work with errors like:
ld: file not found: /Applications/Xcode_14.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.0/lib/darwin/libclang_rt.fuzzer_osx.a
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
| |
There's no guarantee that %j (uintmax_t) is large enough to handle off_t.
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
| |
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
| |
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some binaries use `/proc/self/exe` to get a link to the
currently-executing binary. Unfortunately, when `ld.so` is invoked
directly, `/proc/self/exe` alawys points to `ld.so`.
`LD_ARGV0` can only be used to determine the current executable in
programs which haven't changed their working directory from their
starting one, so that's difficult to generally use.
To solve this, this embeds the path of the current binary _relative to
ld.so_ in an env var.
Bug: https://crbug.com/1003841
Bug: https://issuetracker.google.com/187793259
Signed-off-by: George Burgess <gbiv@chromium.org>
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit b97eba7fb2c0a3c5ad9e3831c6f87dca1fde59c5 causes problems when
using lddtree with symlinks containing absolute paths, such as the
crosvm guest tools, which install these links:
/usr/bin/sommelier -> /etc/alternatives/sommelier ->
/opt/google/cros-containers/bin/sommelier
(where the final sommelier is the lddtree-generated script).
In this case, $base resolved by the lddtree script would be
'/usr/bin//etc/alternatives/sommelier', which is incorrect.
Replace the dirname/readlink combination with readlink -f when the
symlink is absolute in order to fully resolve the symlink, while keeping
the relative path when the script is invoked through a relative path.
Bug: https://crbug.com/882055
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|