glibc AddressSanitizer:DEADLYSIGNAL
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pcre2 (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Hello, I found a crash in glibc 2.31 when fuzzing libpcre2 in Ubuntu 20.04.2 LTS. The input file used to crash the program is attached.
The command to reproduce :
--
sudo apt-get source -y libpcre2-dev
cd pcre2-10.34/
CFLAGS=
make
cd .libs/
export LD_LIBRARY_
cat /tmp/libc_0x1875df | ./pcre2test
--
Output from ASAN :
--
AddressSanitize
=======
==2223969==ERROR: AddressSanitizer: SEGV on unknown address 0x629000010000 (pc 0x7ffff74015e0 bp 0x7fffffff7d70 sp 0x7fffffff74e8 T0)
==2223969==The signal is caused by a READ memory access.
#0 0x7ffff74015df (/lib/x86_
#1 0x7ffff75cef11 (/lib/x86_
#2 0x7ffff753e1f0 in pcre2_match_8 src/pcre2_
#3 0x555555581d6f in process_data src/pcre2test.
#4 0x555555586ce8 in main src/pcre2test.
#5 0x7ffff72a10b2 in __libc_start_main (/lib/x86_
#6 0x55555556a1ad in _start (/tmp/libpcre2-
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/x86_
--
Ubuntu versions and libc versions:
--
kurisu@
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https:/
SUPPORT_URL="https:/
BUG_REPORT_URL="https:/
PRIVACY_
VERSION_
UBUNTU_
kurisu@
GNU C Library (Ubuntu GLIBC 2.31-0ubuntu9.2) stable release version 2.31.
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 9.3.0.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
<https:/
--
information type: | Private Security → Public Security |
affects: | glibc (Ubuntu) → pcre2 (Ubuntu) |
Hello, thanks for reporting this to us.
Fuzzers are fantastic tools but getting good results from them is difficult: they do not actually point out 'the flaw', it still requires significant investigation of the process state to determine what internal inconsistency has been exposed, before fixing the flaw. This investigation and fixing is best carried out together with upstream software authors, who (reasonably enough) usually want to work with the newest version of their software, or a development version of their software.
So, to get the most value from your fuzzing efforts, please:
- fuzz either the most recent release, or development versions, depending upon the project.
- coordinate fuzzing efforts with the project, to find interfaces that need fuzzing and interfaces that do not need fuzzing.
- minimize the test cases, to simplify root-cause analysis.
- prepare a patch; even if not accepted by upstream developers, a patch that addresses a problem often helps narrow down what needs fixing.
- report results directly to upstream developers, in whatever manner they prefer.
Please also consider submitting test harnesses to upstream developers to use Google's oss-fuzz project, https:/ /google. github. io/oss- fuzz/ which will run fuzzers on projects using Google's resources, for free. Many projects could benefit from this service but may not have the time to learn how to do this themselves.
Thanks