Allocation-size-too-big caused by `bytes::BytesMut::zeroed`

version of bytes

1.2.1

Bug description

Allocation-size-too-big found by Address-Sanitizer in fuzzy test. It is recommended to limit the amount of memory allocated to solve this problem.

=================================================================
==24279==ERROR: AddressSanitizer: requested allocation size 0x7878787878787838 (0x7878787878788838 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T0)

    #0 0x100c38545 in wrap_calloc+0xa5 (librustc-nightly_rt.asan.dylib:x86_64+0x49545) (BuildId: 82035263f6573f178111fba8a607607d240000001000000000070a0000010c00)
    #1 0x10088a6bb in alloc::alloc::alloc_zeroed::hebbeb55c480976a2+0x13b (memory_out:x86_64+0x10002c6bb) (BuildId: addafbac26e83a8a80977e9b3b6ff4e832000000200000000100000000000d00)
    #2 0x10088af55 in alloc::alloc::Global::alloc_impl::hf8e86d4625a8f56e+0x305 (memory_out:x86_64+0x10002cf55) (BuildId: addafbac26e83a8a80977e9b3b6ff4e832000000200000000100000000000d00)
    #3 0x10088c7b4 in _$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Allocator$GT$::allocate_zeroed::h566d59218e6fed9b+0x134 (memory_out:x86_64+0x10002e7b4) (BuildId: addafbac26e83a8a80977e9b3b6ff4e832000000200000000100000000000d00)
    #4 0x100881231 in alloc::raw_vec::RawVec$LT$T$C$A$GT$::allocate_in::hfa06af4e63efe7f0+0x8b1 (memory_out:x86_64+0x100023231) (BuildId: addafbac26e83a8a80977e9b3b6ff4e832000000200000000100000000000d00)
    #5 0x100881f3c in alloc::raw_vec::RawVec$LT$T$C$A$GT$::with_capacity_zeroed_in::hb9337ab8c622f96b+0x1c (memory_out:x86_64+0x100023f3c) (BuildId: addafbac26e83a8a80977e9b3b6ff4e832000000200000000100000000000d00)
    #6 0x100878071 in _$LT$u8$u20$as$u20$alloc..vec..spec_from_elem..SpecFromElem$GT$::from_elem::habf2c93b6fc899e9+0x121 (memory_out:x86_64+0x10001a071) (BuildId: addafbac26e83a8a80977e9b3b6ff4e832000000200000000100000000000d00)
    #7 0x1008988e0 in alloc::vec::from_elem::h898c56452bd52cdb+0x20 (memory_out:x86_64+0x10003a8e0) (BuildId: addafbac26e83a8a80977e9b3b6ff4e832000000200000000100000000000d00)
    #8 0x10088cd9b in bytes::bytes_mut::BytesMut::zeroed::h41c00eeedc2f1bfa+0xdb (memory_out:x86_64+0x10002ed9b) (BuildId: addafbac26e83a8a80977e9b3b6ff4e832000000200000000100000000000d00)
    #9 0x10086b4c1 in memory_out::test_function31::hd16380c9421032e2 main.rs:30
    #10 0x10086c4db in memory_out::main::hc01f69f1feafccba main.rs:63
    #11 0x10086215d in core::ops::function::FnOnce::call_once::h4ddefdf333e0463e function.rs:248
    #12 0x100874b13 in std::sys_common::backtrace::__rust_begin_short_backtrace::hc2e1e4bd77335a42 backtrace.rs:122
    #13 0x10086e83f in std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h431c9c7ed1cffbb1 rt.rs:145
    #14 0x1008b21f9 in std::rt::lang_start_internal::hdab059415f47b88c+0x2a9 (memory_out:x86_64+0x1000541f9) (BuildId: addafbac26e83a8a80977e9b3b6ff4e832000000200000000100000000000d00)
    #15 0x10086e789 in std::rt::lang_start::h6200b9947110a6d4 rt.rs:144
    #16 0x10086c645 in main+0x15 (memory_out:x86_64+0x10000e645) (BuildId: addafbac26e83a8a80977e9b3b6ff4e832000000200000000100000000000d00)
    #17 0x7ff8078dd30f  (<unknown module>)

==24279==HINT: if you don't care about these errors you may set allocator_may_return_null=1
SUMMARY: AddressSanitizer: allocation-size-too-big (librustc-nightly_rt.asan.dylib:x86_64+0x49545) (BuildId: 82035263f6573f178111fba8a607607d240000001000000000070a0000010c00) in wrap_calloc+0xa5
==24279==ABORTING
[1]    24279 abort      ./target/debug/memory_out ../crash_input

Steps to reproduce the behavior

Using auto-generated fuzz target can reproduce the behavior. it was uploaded to the issue platform. allocation-size-too-big.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

tokio-rs / bytes