Date: Wed, 12 Jan 2022 01:54:19 -0800 From: Mark Millard <marklmi@yahoo.com> To: freebsd-current <freebsd-current@freebsd.org> Subject: kyua run under WITH_ASAN= built world reports a global-buffer-overflow during cpio test. Message-ID: <313A3FD8-1E8C-46C2-A400-E0A647F09464@yahoo.com> References: <313A3FD8-1E8C-46C2-A400-E0A647F09464.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
For the below it appears that the report from UBSAN is accurate.
=3D=3D85511=3D=3DERROR: AddressSanitizer: global-buffer-overflow on =
address 0x0000010753ca at pc 0x000001139bda bp 0x7fffffffc2b0 sp =
0x7fffffffc2a8
READ of size 1 at 0x0000010753ca thread T0
#0 0x1139bd9 in hexdump =
/usr/main-src/contrib/libarchive/test_utils/test_main.c:875:35
#1 0x113b73c in assertion_text_file_contents =
/usr/main-src/contrib/libarchive/test_utils/test_main.c:1182:3
#2 0x1125d46 in basic_cpio =
/usr/main-src/contrib/libarchive/cpio/test/test_basic.c:84:2
#3 0x11259dc in test_basic =
/usr/main-src/contrib/libarchive/cpio/test/test_basic.c:229:2
#4 0x1144943 in test_run =
/usr/main-src/contrib/libarchive/test_utils/test_main.c:3561:2
#5 0x1144943 in main =
/usr/main-src/contrib/libarchive/test_utils/test_main.c:4062:9
0x0000010753ca is located 54 bytes to the left of global variable =
'<string literal>' defined in =
'/usr/main-src/contrib/libarchive/cpio/test/test_basic.c:229:13' =
(0x1075400) of size 5
'<string literal>' is ascii string 'copy'
0x0000010753ca is located 22 bytes to the left of global variable =
'<string literal>' defined in =
'/usr/main-src/contrib/libarchive/cpio/test/test_basic.c:228:38' =
(0x10753e0) of size 9
'<string literal>' is ascii string '1 block
'
0x0000010753ca is located 0 bytes to the right of global variable =
'<string literal>' defined in =
'/usr/main-src/contrib/libarchive/cpio/test/test_basic.c:220:18' =
(0x10753c0) of size 10
'<string literal>' is ascii string '2 blocks
'
SUMMARY: AddressSanitizer: global-buffer-overflow =
/usr/main-src/contrib/libarchive/test_utils/test_main.c:875:35 in =
hexdump
Shadow bytes around the buggy address:
0x40000020ea20: f9 f9 f9 f9 02 f9 f9 f9 00 01 f9 f9 00 02 f9 f9
0x40000020ea30: 00 00 00 00 00 00 02 f9 f9 f9 f9 f9 00 f9 f9 f9
0x40000020ea40: 00 01 f9 f9 00 00 00 00 00 00 01 f9 f9 f9 f9 f9
0x40000020ea50: 06 f9 f9 f9 07 f9 f9 f9 00 00 00 00 00 07 f9 f9
0x40000020ea60: f9 f9 f9 f9 04 f9 f9 f9 05 f9 f9 f9 00 00 00 00
=3D>0x40000020ea70: 00 05 f9 f9 f9 f9 f9 f9 00[02]f9 f9 00 01 f9 f9
0x40000020ea80: 05 f9 f9 f9 01 f9 f9 f9 00 01 f9 f9 00 05 f9 f9
0x40000020ea90: 00 02 f9 f9 00 f9 f9 f9 00 02 f9 f9 07 f9 f9 f9
0x40000020eaa0: 00 01 f9 f9 07 f9 f9 f9 00 02 f9 f9 00 02 f9 f9
0x40000020eab0: 00 03 f9 f9 00 01 f9 f9 00 04 f9 f9 00 00 00 00
0x40000020eac0: 00 00 00 03 f9 f9 f9 f9 00 00 00 f9 f9 f9 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07=20
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
=3D=3D85511=3D=3DABORTING
Well, contrib/libarchive/cpio/test/test_basic.c:84 is doing:
assertTextFileContents(se, "pack.err");
which involves, in turn:
int
assertion_text_file_contents(const char *filename, int line, const char =
*buff, const char *fn)
{
. . .
s =3D (int)strlen(buff);
contents =3D malloc(s * 2 + 128);
n =3D (int)fread(contents, 1, s * 2 + 128 - 1, f);
. . .
if (n > 0) {
hexdump(contents, buff, n, 0);
. . .
Nothing about the code seems to constrain n to fit the
size of the space for "pack.err" (9 bytes of "global"
space).
The report is for the ref[i + j] in the code:
static void
hexdump(const char *p, const char *ref, size_t l, size_t offset)
{
. . .
for (j =3D 0; j < 16 && i + j < l; j++) {
if (ref !=3D NULL && p[i + j] !=3D ref[i + j])
. . .
where ref points to the space for "pack.err" and l was
given a copy of the value of n in the previously shown
code.
The i + j < l constraint need not avoid the code doing
ref[i + j] in a way that reaches outside the space for
"pack.err" --because of the supplied value of n (a.k.a. l)
not being sufficient to respect the space for "pack.err".
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?313A3FD8-1E8C-46C2-A400-E0A647F09464>