Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect / Inconsistent result produced by curl_fuzzer #50

Open
shao-hua-li opened this issue Dec 13, 2021 · 6 comments
Open

Incorrect / Inconsistent result produced by curl_fuzzer #50

shao-hua-li opened this issue Dec 13, 2021 · 6 comments
Assignees

Comments

@shao-hua-li
Copy link

Hi there,

I compiled curl-fuzzer using ./mainline.sh with gcc11 and clang13 separately. I found that for some inputs, the two compiled curl_fuzzer would emit different results.

  • Compiler: gcc11 and clang13
  • Platform: Ubuntu 20.04.4 LTS, x86_64
  • INPUT: diff_line_number.tar.gz (decompress it first)

Let curl_fuzzer_gcc11 denote gcc11 compiled curl_fuzzer; curl_fuzzer_clang13 denote clang13 compiled one. Reproduce as follows:

$ FUZZ_VERBOSE=yes ./curl_fuzzer_gcc11 diff_line_number > out_gcc11
$ 
$ FUZZ_VERBOSE=yes ./curl_fuzzer_clang13 diff_line_number > out_clang13
$ 
$ diff out_gcc11 out_clang13
< * STATE: CONNECTING => PROTOCONNECT handle ; line 2014 (connection #0)
---
> * STATE: CONNECTING => PROTOCONNECT handle ; line 2012 (connection #0)
@cmeister2
Copy link
Collaborator

Thanks for the report! I'll try and look into it shortly.

@cmeister2 cmeister2 self-assigned this Dec 13, 2021
@shao-hua-li
Copy link
Author

Thanks for the report! I'll try and look into it shortly.

BTW, I disabled all sanitizers when compiling.

@cmeister2
Copy link
Collaborator

@shao-hua-li I've tried to build the fuzzers using docker's gcc:11 image and I'm struggling to get there; mostly having issues in building curl itself statically.

Did you have to do anything radical to get this building on your local system?

@shao-hua-li
Copy link
Author

@shao-hua-li I've tried to build the fuzzers using docker's gcc:11 image and I'm struggling to get there; mostly having issues in building curl itself statically.

Did you have to do anything radical to get this building on your local system?

Hi, I did the following:

  • change "export CC=clang export CXX=clang++" to gcc and g++
  • remove "-fsanitize=address -stdlib=libstdc++" from mainline.sh and compiled standalone_fuzz_target_runner.cc to libstandaloneengine.a

@cmeister2
Copy link
Collaborator

cmeister2 commented Dec 16, 2021

I don't appear to be able to reproduce this using docker versions of gcc-11 and clang-13. The only potential difference here is that the 3 line multistate macro call in multi.c is attributed to line 2028 in gcc, and 2030 in clang.

--- diff_line_number.gcc11.txt  2021-12-16 13:52:34.335167312 +0000
+++ diff_line_number.clang13.txt        2021-12-16 14:17:14.783114645 +0000
@@ -1,20 +1,20 @@
-* STATE: INIT => CONNECT handle 0x1908288; line 1835 (connection #-5000)
+* STATE: INIT => CONNECT handle 0x622000000108; line 1835 (connection #-5000)
 * Connecting to hostname: 127.0.1.127
 * Added connection 0. The cache now contains 1 members
 * family0 == v4, family1 == v6
 *   Trying 127.0.1.127:80...
 * Could not set TCP_NODELAY: Operation not supported
-* STATE: CONNECT => CONNECTING handle 0x1908288; line 1896 (connection #0)
+* STATE: CONNECT => CONNECTING handle 0x622000000108; line 1896 (connection #0)
 * Connected to 127.0.1.127 () port 80 (#0)
-* STATE: CONNECTING => PROTOCONNECT handle 0x1908288; line 2028 (connection #0)
-* STATE: PROTOCONNECT => DO handle 0x1908288; line 2051 (connection #0)
+* STATE: CONNECTING => PROTOCONNECT handle 0x622000000108; line 2030 (connection #0)
+* STATE: PROTOCONNECT => DO handle 0x622000000108; line 2051 (connection #0)
 > GET / HTTP/1.1
 Host: 127.0.0.1
 Accept: */*
-Accept-Encoding: deflate, gzip, br
+Accept-Encoding: deflate, gzip

-* STATE: DO => DID handle 0x1908288; line 2147 (connection #0)
-* STATE: DID => PERFORMING handle 0x1908288; line 2266 (connection #0)
+* STATE: DO => DID handle 0x622000000108; line 2147 (connection #0)
+* STATE: DID => PERFORMING handle 0x622000000108; line 2266 (connection #0)
 * Mark bundle as not supporting multiuse
 * HTTP 1.1 or later with persistent connection
 < HTTP/1.1 200 OK
@@ -23,11 +23,11 @@
 < Content-Length: 110
 < Content-Encoding: gzip
 <
-* STATE: PERFORMING => DONE handle 0x1908288; line 2465 (connection #0)
+* STATE: PERFORMING => DONE handle 0x622000000108; line 2465 (connection #0)
 * multi_done: status: 0 prem: 0 done: 0
 * Connection #0 to host 127.0.1.127 left intact
-* Expire cleared (transfer 0x1908288)
-[./diff_line_number] Opened.. Read 278 bytes, fuzzing.. TLV: type 1 length 17
+* Expire cleared (transfer 0x622000000108)
+[../diff_line_number] Opened.. Read 278 bytes, fuzzing.. TLV: type 1 length 17
 Check length of data: 23
 Remaining length of data: 278
 TLV: type 2 length 243

If that is the same result as yours - I don't think there's much we can do about it. I don't know if __LINE__ behaviour is defined differently in both compilers.

@shao-hua-li
Copy link
Author

shao-hua-li commented Jan 3, 2022

Hi, I also observed that the Accept-Encoding:xxx were different between them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants