Potential OOM / large allocation issue in `TopicPartitionList::with_capacity(usize)`

[cicilzx]

Hi, I'm currently developing a fuzzer to test safe abstractions in Rust crates. I ran into a case where calling TopicPartitionList::with_capacity with a very large usize can trigger an out-of-memory abort under AddressSanitizer. I’m not sure whether this is expected behavior, but I wanted to report it in case a small guard or documentation note could improve robustness.

Environment

• OS: Linux x86_64 (Ubuntu)
• Rust toolchain: nightly-2024-12-15
• rdkafka version: 0.39.0
• Sanitizer: AddressSanitizer (ASan)

Minimal reproduction

extern crate rdkafka;

fn main() {
    let capacity: usize = 6294967296;
    println!("usize: {}", capacity);
    let _ = rdkafka::topic_partition_list::TopicPartitionList::with_capacity(capacity);
}

Observed output (ASan)

=================================================================
==3045310==ERROR: AddressSanitizer: out of memory: allocator is trying to allocate 0x1dcd650000 bytes
    #0 0x5d4b409d0f0c  (/home/.../target/debug/test1+0x15cf0c) (BuildId: ...)
    #1 0x5d4b40a8974a  (/home/.../target/debug/test1+0x21574a) (BuildId: ...)

==3045310==HINT: if you don't care about these errors you may set allocator_may_return_null=1
SUMMARY: AddressSanitizer: out-of-memory ...
==3045310==ABORTING

Notes

In normal usage, callers probably won’t pass capacities this large, but it seems possible to accidentally provide an unexpectedly big value (e.g., from unvalidated input or a bug upstream), which can lead to a very large allocation attempt and an OOM abort. Since the code performs a narrowing cast (capacity as i32) before calling the underlying C API, it might be worth considering a small guard before the cast (for example, rejecting values larger than i32::MAX as usize, or otherwise handling them in a predictable way), or adding a brief note in the docs that the maximum capacity is limited to i32::MAX. If this is considered expected behavior, please feel free to close. I just wanted to share it in case a lightweight check or clarification would make the API more robust.

Thanks for taking a look!