alamb opened a new issue, #10973: URL: https://github.com/apache/arrow-rs/issues/10973
## Describe the bug [`MutableBuffer::collect_bool`](https://github.com/apache/arrow-rs/blob/main/arrow-buffer/src/buffer/mutable.rs) reserves `ceil(len / 64)` u64 words up front, so a large `len` aborts the process before the closure is ever called. In theory, `len` can come from a row or bit count that originates in user controlled data. ## To Reproduce With arrow-buffer 59.2.0: ```toml [dependencies] arrow-buffer = "59.2.0" ``` ```rust use arrow_buffer::MutableBuffer; fn main() { let bits: usize = std::env::args() .nth(1) .and_then(|s| s.parse().ok()) .unwrap_or(1usize << 60); println!( "calling MutableBuffer::collect_bool with len = {bits} bits \ ({} bytes of backing storage)", bits / 8 ); let mut calls = 0usize; let buf = MutableBuffer::collect_bool(bits, |_| { calls += 1; true }); println!("returned {} bytes, closure called {calls} times", buf.len()); } ``` Here is the full repro: ```shell andrewlamb@Andrews-MacBook-Pro-3:/tmp/issue2_repro$ cargo run Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.01s Running `target/debug/issue2_repro` calling MutableBuffer::collect_bool with len = 1152921504606846976 bits (144115188075855872 bytes of backing storage) memory allocation of 144115188075855872 bytes failed note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Abort trap: 6 cargo run andrewlamb@Andrews-MacBook-Pro-3:/tmp/issue2_repro$ cargo run --release Finished `release` profile [optimized] target(s) in 0.01s Running `target/release/issue2_repro` calling MutableBuffer::collect_bool with len = 1152921504606846976 bits (144115188075855872 bytes of backing storage) memory allocation of 144115188075855872 bytes failed note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Abort trap: 6 cargo run --release ``` The closure is never called, which shows the allocation happens before any iteration. ## Expected behavior Allocating based on `len` is by design here (the same is true of `Vec::with_capacity`), so I recommend documenting that callers must validate untrusted counts first ## Additional context - Reported privately to the ASF security list, but the PMC assessed it as a bug per the [arrow-rs security policy](https://github.com/apache/arrow-rs/blob/main/SECURITY.md) since it does not enable code execution or data disclosure (see also #9898 for a similar precedent). - Affected versions: verified against arrow-rs 59.2.0 (`arrow-buffer`); earlier versions likely also affected. - Reporter-suggested CWE classifications: CWE-770 (allocation without limits), CWE-703 (improper check of exceptional conditions). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
