Stack buffer underflow (read) in `xbps_path_rel`
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 55/100
Hướng nghiên cứu
Start with util_path.c at line 151 and inspect xbps_path_rel using the A/B inputs from testcase.cpp. Build the revision with the provided Dockerfile and run the AddressSanitizer command to reproduce the report. Done means the testcase no longer produces a stack-buffer-underflow report.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Hi, there is a potential bug in xbps_path_rel when invoked with certain paths.
This bug was reproduced on https://github.com/void-linux/xbps/commit/25fba2eb00eed513709d7545030b30871f9a8f8c.
Description
What crashes:
- AddressSanitizer reports a stack-buffer-underflow (read) in xbps_path_rel at util_path.c:151. The report shows the access underflows the local array 'frombuf' by one byte. The relevant code snippet is:
for (up = -1, fromp--; fromp && *fromp; fromp = strchr(fromp+1, '/'), up++) ;
Here, fromp points into 'frombuf'. The expression 'fromp--' unconditionally decrements it, and the immediately following loop condition dereferences '*fromp' without ensuring fromp is still within the array bounds. If fromp was at the beginning of 'frombuf' (which occurs for short/simple inputs), '*fromp' reads one byte before 'frombuf'.
It could be safer to check fromp before dereferencing it, ensuring it is within bounds of the string. Alternatively, if there are certain requirements on input strings, those could be documented.
POC
The following testcase demonstrates the bug:
testcase.cpp
#include <cstddef>
#include <sys/types.h>
extern "C" ssize_t xbps_path_rel(char *dst, size_t len, const char *from, const char *to);
int main(){
char dst[16];
const char *from = "A";
const char *to = "B";
(void)xbps_path_rel(dst, sizeof(dst), from, to);
return 0;
}
stdout
stderr
=================================================================
==1==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7f3572e0001f at pc 0x7f3577170caa bp 0x7fff5bd0cbb0 sp 0x7fff5bd0cba8
READ of size 1 at 0x7f3572e0001f thread T0
#0 0x7f3577170ca9 in xbps_path_rel /fuzz/src/lib/util_path.c:151:34
#1 0x563df195c4dd in main /fuzz/testcase.cpp:8:11
#2 0x7f35764a9d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#3 0x7f35764a9e3f in __libc_start_main csu/../csu/libc-start.c:392:3
#4 0x563df18812f4 in _start (/fuzz/test+0x2c2f4) (BuildId: a951573eded97d52362734781c8eb16094d3f9f8)
Address 0x7f3572e0001f is located in stack of thread T0 at offset 31 in frame
#0 0x7f35771709bf in xbps_path_rel /fuzz/src/lib/util_path.c:132
This frame has 2 object(s):
[32, 4128) 'frombuf' (line 133) <== Memory access at offset 31 underflows this variable
[4256, 8352) 'tobuf' (line 133)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow /fuzz/src/lib/util_path.c:151:34 in xbps_path_rel
Shadow bytes around the buggy address:
0x7f3572dffd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f3572dffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f3572dffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f3572dfff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f3572dfff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x7f3572e00000: f1 f1 f1[f1]00 00 00 00 00 00 00 00 00 00 00 00
0x7f3572e00080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f3572e00100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f3572e00180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f3572e00200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f3572e00280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==1==ABORTING
Steps to Reproduce
The crash was triaged with the following Dockerfile:
Dockerfile
# Ubuntu 22.04 with some packages pre-installed
FROM hgarrereyn/stitch_repro_base@sha256:3ae94cdb7bf2660f4941dc523fe48cd2555049f6fb7d17577f5efd32a40fdd2c
RUN git clone https://github.com/void-linux/xbps /fuzz/src && \
cd /fuzz/src && \
git checkout 25fba2eb00eed513709d7545030b30871f9a8f8c && \
git submodule update --init --remote --recursive
ENV LD_LIBRARY_PATH=/fuzz/install/lib
ENV ASAN_OPTIONS=hard_rss_limit_mb=1024:detect_leaks=0
RUN echo '#!/bin/bash\nexec clang-17 -fsanitize=address -O0 "$@"' > /usr/local/bin/clang_wrapper && \
chmod +x /usr/local/bin/clang_wrapper && \
echo '#!/bin/bash\nexec clang++-17 -fsanitize=address -O0 "$@"' > /usr/local/bin/clang_wrapper++ && \
chmod +x /usr/local/bin/clang_wrapper++
# Install build and runtime dependencies for libxbps
RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
build-essential \
pkg-config \
zlib1g-dev \
libarchive-dev \
libssl-dev \
liblz4-dev \
libzstd-dev \
libbz2-dev \
liblzma-dev \
ca-certificates \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /fuzz/src
# Configure, build, and install
ENV CC=clang_wrapper CXX=clang_wrapper++
RUN ./configure --prefix=/fuzz/install && \
make -j"$(nproc)" && \
make install
Build Command
clang++-17 -fsanitize=address -g -O0 -o /fuzz/test /fuzz/testcase.cpp -I/fuzz/install/include -L/fuzz/install/lib -lxbps -larchive -lz -llz4 -lzstd -lbz2 -llzma -lssl -lcrypto && /fuzz/test
Reproduce
- Copy
Dockerfileandtestcase.cppinto a local folder. - Build the repro image:
docker build . -t repro --platform=linux/amd64
- Compile and run the testcase in the image:
docker run \
-it --rm \
--platform linux/amd64 \
--mount type=bind,source="$(pwd)/testcase.cpp",target=/fuzz/testcase.cpp \
repro \
bash -c "clang++-17 -fsanitize=address -g -O0 -o /fuzz/test /fuzz/testcase.cpp -I/fuzz/install/include -L/fuzz/install/lib -lxbps -larchive -lz -llz4 -lzstd -lbz2 -llzma -lssl -lcrypto && /fuzz/test"
Additional Info
This testcase was discovered by STITCH, an autonomous fuzzing system. All reports are reviewed manually (by a human) before submission.
- Ngôn ngữ chính
- C
- Star
- 1.2k
- Fork
- 154
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của void-linux/xbps
-
Typo in configureCó thể đã có người làm @Jah-yee đã nhận 4 ngày trước. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
void-linux/xbps#704 ·
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 68/100
void-linux/xbps#475 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
void-linux/xbps#701 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
void-linux/xbps#700 ·
-
xbps-query -RX repository overridesCó thể đã có người làm @outofsyncrs đã nhận 40 ngày trước. Đang mởbug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 45/100
void-linux/xbps#696 ·
Tất cả issue của void-linux/xbps
Issue tương tự
-
[raylib] update to 6.2Đang mởcategory:port-update
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
Maintainer thường phản hồi trong vòng 8 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
Maintainer thường phản hồi trong vòng 1 ngày