Created attachment 848303 [details] testcase+log A crafted ELF file causes a memory WRITE issue: $ scanmacho -Aa 445.crashes.elf ==3090==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000000f at pc 0x555555641071 bp 0x7fffffffd970 sp 0x7fffffffd968 WRITE of size 1 at 0x60200000000f thread T0 #0 0x555555641070 in ar_next /var/tmp/portage/app-misc/pax-utils-1.3.6-r1/work/pax-utils-1.3.6-build/../pax-utils-1.3.6/paxinc.c:96:20 #1 0x55555563d623 in scanmacho_archive /var/tmp/portage/app-misc/pax-utils-1.3.6-r1/work/pax-utils-1.3.6-build/../pax-utils-1.3.6/scanmacho.c:430:14 #2 0x55555563d623 in scanmacho_file /var/tmp/portage/app-misc/pax-utils-1.3.6-r1/work/pax-utils-1.3.6-build/../pax-utils-1.3.6/scanmacho.c:476:3 #3 0x55555563c811 in scanmacho_dir /var/tmp/portage/app-misc/pax-utils-1.3.6-r1/work/pax-utils-1.3.6-build/../pax-utils-1.3.6/scanmacho.c:500:10 #4 0x55555563ba60 in parseargs /var/tmp/portage/app-misc/pax-utils-1.3.6-r1/work/pax-utils-1.3.6-build/../pax-utils-1.3.6/scanmacho.c:803:9 #5 0x55555563ba60 in main /var/tmp/portage/app-misc/pax-utils-1.3.6-r1/work/pax-utils-1.3.6-build/../pax-utils-1.3.6/scanmacho.c:816:8 #6 0x7ffff7d0e1f6 in __libc_start_call_main /var/tmp/portage/sys-libs/glibc-2.36-r5/work/glibc-2.36/csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #7 0x7ffff7d0e2ab in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.36-r5/work/glibc-2.36/csu/../csu/libc-start.c:381:3 #8 0x555555578610 in _start (/usr/bin/scanmacho+0x24610) Testcase and complete log attached as a zip
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pax-utils.git/commit/?id=5b5556d12b96dd2d420e0d66456f1935668b3984 commit 5b5556d12b96dd2d420e0d66456f1935668b3984 Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2024-01-25 04:33:40 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2024-01-25 04:33:40 +0000 ar: handle invalid ascii numbers better 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> paxinc.c | 53 +++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 45 insertions(+), 8 deletions(-)
Are there any objections to requesting a CVE?
pax-utils enable decent seccomp filters on itself, and all the tools are almost entirely read-only tools (scanelf has a --fix option for a limited set of things), so the best you could hope for is a DoS. you aren't getting arbitrary codeexec here, and def not forking+execing other programs. which is to say, i could not care less about CVE's about any read-out-of-bounds crash. i won't stop you from requesting CVEs if you want some public credit for your resume or something. NB: i don't mean this disparagingly -- recognition of contributions is important, and this sort of thing can help in the professional world. i can update the docs to provide this info.
No fixed version in tree, dropping version from summary. Maintainers, please make a fixed release or backport the patch.
