heap-buffer-overflow when calling `bytes::buf::UninitSlice::write_byte`

bhao-Soo commented 1 year ago

version of bytes

1.2.1

Bug description

Heap-buffer-overflow found by Address-Sanitizer in fuzzy test because src/buf/uninit_slice.rs:76 unsafe write operation.

=================================================================
==25773==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x640000000020 at pc 0x0001019232e3 bp 0x7ff7be9bb590 sp 0x7ff7be9bad60
WRITE of size 1 at 0x640000000020 thread T0
    #0 0x1019232e2 in __asan_memcpy+0x262 (librustc-nightly_rt.asan.dylib:x86_64+0x472e2) (BuildId: 82035263f6573f178111fba8a607607d240000001000000000070a0000010c00)
    #1 0x101579cc8 in core::ptr::write::hc794038e3ee0e31b+0x108 (heap_buffer_overflow:x86_64+0x100036cc8) (BuildId: ab5c340117833b5894b289d483c196eb32000000200000000100000000000d00)
    #2 0x101556adf in bytes::buf::uninit_slice::UninitSlice::write_byte::h8938a1f58a23bbae uninit_slice.rs:76
    #3 0x101549009 in heap_buffer_overflow::test_function0::h1c7760f1db031b62 main.rs:38
    #4 0x10154a1f0 in heap_buffer_overflow::main::h09816a705391a0d8 main.rs:76
    #5 0x101560e3d in core::ops::function::FnOnce::call_once::hac0804a27f95cf54 function.rs:248
    #6 0x10155a3b3 in std::sys_common::backtrace::__rust_begin_short_backtrace::h8da9f2ace551bd4c backtrace.rs:122
    #7 0x10154b9cf in std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h9633e8de025d5525 rt.rs:145
    #8 0x10159a919 in std::rt::lang_start_internal::hdab059415f47b88c+0x2a9 (heap_buffer_overflow:x86_64+0x100057919) (BuildId: ab5c340117833b5894b289d483c196eb32000000200000000100000000000d00)
    #9 0x10154b919 in std::rt::lang_start::h38f2d81be78f4569 rt.rs:144
    #10 0x10154a365 in main+0x15 (heap_buffer_overflow:x86_64+0x100007365) (BuildId: ab5c340117833b5894b289d483c196eb32000000200000000100000000000d00)
    #11 0x7ff8078dd30f  (<unknown module>)

Address 0x640000000020 is a wild pointer inside of access range of size 0x000000000001.
SUMMARY: AddressSanitizer: heap-buffer-overflow (librustc-nightly_rt.asan.dylib:x86_64+0x472e2) (BuildId: 82035263f6573f178111fba8a607607d240000001000000000070a0000010c00) in __asan_memcpy+0x262
Shadow bytes around the buggy address:
  0x1c7fffffffb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c7fffffffc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c7fffffffd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c7fffffffe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c7ffffffff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1c8000000000: fa fa fa fa[fa]fa fa fa fa fa fa fa fa fa fa fa
  0x1c8000000010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c8000000020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c8000000030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c8000000040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c8000000050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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
==25773==ABORTING
[1]    25773 abort      ./target/debug/heap_buffer_overflow ../crash_input

Steps to reproduce the behavior

Using auto-generated fuzz target can reproduce the behavior. it was uploaded to the issue platform. heap-buffer-overflow.zip

when complier the file with cargo, following the Instruction: export RUSTFLAGS=-Zsanitizer=address RUSTDOCFLAGS=-Zsanitizer=address cargo +nightly build

run the executive file with the crash input file to reproduce the behavior

Darksonn commented 1 year ago

The pointer you pass to UninitSlice when you create it must point into an actual allocation of the given length. If you give it a dangling address, then it is no surprise that it wont work.

I see you have opened multiple issues that look like this in quick succession. Please verify that they are actually issues before opening a bug report.

bhao-Soo commented 1 year ago

It is very sorry to bother you. I just want to know the reason of the error. Thank you very much for your timely reply, and now I understand.

tokio-rs / bytes