[BUG] A heap-buffer-overflow in `hashmap_set_with_hash` at `gumbo-parser/src/hashmap.c:286:5`

[JJLeo]

Description

• Version: Latest commit a024cff
• Environment: Ubuntu 20.04.6 LTS, Clang 18.1.8
• Fuzzing harness: https://github.com/sparklemotion/nokogiri/blob/main/gumbo-parser/fuzzer/parse_fuzzer.cc

Please let me know if you encounter any issues reproducing it — I can upload a Docker image to help.

Steps to reproduce

cd nokogiri/gumbo-parser
export CC="clang"
export CXX="clang++"
export CFLAGS="-fsanitize=address -g -O0 -fno-omit-frame-pointer"
export CXXFLAGS="-fsanitize=address -g -O0 -fno-omit-frame-pointer -stdlib=libc++"
export LIB_FUZZING_ENGINE="-fsanitize=fuzzer"
export OUT=$PWD
make oss-fuzz CFLAGS="$CFLAGS" CXXFLAGS="$CXXFLAGS"
./parse_fuzzer $POC

Sanitizer output

root@67d74d8702cc:/src/nokogiri/gumbo-parser# ./parse_fuzzer /root/nokogiri_crash.txt 
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 3305694978
INFO: Loaded 1 modules   (28 inline 8-bit counters): 28 [0x5f0fccac1440, 0x5f0fccac145c), 
INFO: Loaded 1 PC tables (28 PCs): 28 [0x5f0fccac1460,0x5f0fccac1620), 
./parse_fuzzer: Running 1 inputs 1 time(s) each.
Running: /root/nokogiri_crash.txt
=================================================================
==5312==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x502000000174 at pc 0x5f0fcc941fb2 bp 0x7fff0a23b0b0 sp 0x7fff0a23a870
READ of size 8 at 0x502000000174 thread T0
    #0 0x5f0fcc941fb1 in __asan_memcpy /src/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:63:3
    #1 0x5f0fcc9fb81c in hashmap_set_with_hash /src/nokogiri/gumbo-parser/src/hashmap.c:286:5
    #2 0x5f0fcc9fc08c in hashmap_set /src/nokogiri/gumbo-parser/src/hashmap.c:321:12
    #3 0x5f0fcc9f9cac in gumbo_string_set_insert /src/nokogiri/gumbo-parser/src/string_set.c:34:3
    #4 0x5f0fcc9adfda in finish_attribute_name /src/nokogiri/gumbo-parser/src/tokenizer.c:812:7
    #5 0x5f0fcc9a6f47 in handle_attr_name_state /src/nokogiri/gumbo-parser/src/tokenizer.c:1808:7
    #6 0x5f0fcc9a42ad in gumbo_lex /src/nokogiri/gumbo-parser/src/tokenizer.c:3444:26
    #7 0x5f0fcc984c9e in gumbo_parse_with_options /src/nokogiri/gumbo-parser/src/parser.c:4798:9
    #8 0x5f0fcc98406a in LLVMFuzzerTestOneInput /src/nokogiri/gumbo-parser/fuzzer/parse_fuzzer.cc:46:25
    #9 0x5f0fcc8382f0 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #10 0x5f0fcc823565 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #11 0x5f0fcc828fff in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #12 0x5f0fcc8542a2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #13 0x7449cc7c6082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
    #14 0x5f0fcc81b74d in _start (/src/nokogiri/gumbo-parser/parse_fuzzer+0x5174d)

0x502000000174 is located 0 bytes after 4-byte region [0x502000000170,0x502000000174)
allocated by thread T0 here:
    #0 0x5f0fcc9440bf in malloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:68:3
    #1 0x5f0fcc9b1984 in gumbo_alloc /src/nokogiri/gumbo-parser/src/util.c:25:15
    #2 0x5f0fcc9a12c1 in gumbo_string_buffer_to_string /src/nokogiri/gumbo-parser/src/string_buffer.c:91:18
    #3 0x5f0fcc9ae6d5 in copy_over_tag_buffer /src/nokogiri/gumbo-parser/src/tokenizer.c:711:13
    #4 0x5f0fcc9ae4e3 in finish_attribute_name /src/nokogiri/gumbo-parser/src/tokenizer.c:841:5
    #5 0x5f0fcc9a6f47 in handle_attr_name_state /src/nokogiri/gumbo-parser/src/tokenizer.c:1808:7
    #6 0x5f0fcc9a42ad in gumbo_lex /src/nokogiri/gumbo-parser/src/tokenizer.c:3444:26
    #7 0x5f0fcc984c9e in gumbo_parse_with_options /src/nokogiri/gumbo-parser/src/parser.c:4798:9
    #8 0x5f0fcc98406a in LLVMFuzzerTestOneInput /src/nokogiri/gumbo-parser/fuzzer/parse_fuzzer.cc:46:25
    #9 0x5f0fcc8382f0 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #10 0x5f0fcc823565 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #11 0x5f0fcc828fff in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #12 0x5f0fcc8542a2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #13 0x7449cc7c6082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)

SUMMARY: AddressSanitizer: heap-buffer-overflow /src/nokogiri/gumbo-parser/src/hashmap.c:286:5 in hashmap_set_with_hash
Shadow bytes around the buggy address:
  0x501ffffffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x501fffffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x501fffffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x502000000000: fa fa 00 00 fa fa 00 fa fa fa 00 fa fa fa 00 fa
  0x502000000080: fa fa 00 fa fa fa 05 fa fa fa 05 fa fa fa fd fa
=>0x502000000100: fa fa fd fa fa fa 02 fa fa fa fd fa fa fa[04]fa
  0x502000000180: fa fa 01 fa fa fa fd fa fa fa 02 fa fa fa 01 fa
  0x502000000200: fa fa fd fd fa fa fd fa fa fa 03 fa fa fa 01 fa
  0x502000000280: fa fa fd fa fa fa 03 fa fa fa 01 fa fa fa fd fa
  0x502000000300: fa fa 02 fa fa fa 01 fa fa fa fd fa fa fa 02 fa
  0x502000000380: fa fa 01 fa fa fa fd fa fa fa 03 fa fa fa 01 fa
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
==5312==ABORTING

POC

nokogiri_crash.txt

Credit

Reported by Yifan Zhang, PLL

[flavorjones]

@JJLeo Thank you for reporting. We'll take a look.

[mattnowzari]

Hello! 👋

This bug is coming up as a CVE, and given that is appears to affect version 1.18.8, we were wondering if a fix was on the roadmap for the upcoming release of nokogiri? If so, would that release would be coming within the next 3 weeks?

[flavorjones]

I am as surprised as you are that someone filed a CVE for this. I have not yet investigated and it has been low on my priority list.

It's extremely annoying that someone would do this, as there is a very clearly described security program on HackerOne which is where security issues should be communicated.

@JJLeo Did you file this CVE?

[flavorjones]

@mattnowzari To try to answer your question: I'll allocate some time to investigating in the next few days, at which point I can tell you if/when a fix will be available. If you'd like to help, I would welcome that effort.

[mattnowzari]

@flavorjones Thank you for the quick response! I will try to poke around as well, if I find anything I'll bring it up here 🙂

[flavorjones]

I've got a fix ready for this.

[flavorjones]

See #3524

[flavorjones]

Note for anyone following this issue: the vulnerable code was never released, and only exists on the unreleased main branch. I will be asking for the CVE to be removed/edited to reflect this.

[flavorjones]

@JJLeo Thanks again for the bug report. However, you have created unnecessary work for me by filing invalid CVEs without my consent, which I now have to figure out how to get rejected.

I considered blocking you from interacting with this project any further, but instead I will be kind and simply give you a warning. If you wish to communicate with me about security-related issues again, do so using the published security reporting process in SECURITY.md. Do not publish CVEs on this project again without communicating with me using that channel.

I sincerely hope you change your behavior in the future to be more collaborative, because this experience has made me extremely hesitant to work with you again.