Hi, I am scanning this crate in the latest version using my own static analyzer tool.
Unsafe pointer conversion is found at:
pub fn write<WF>(&mut self, frames: u32, write_fn: WF) -> Result<(), Error>
where
WF: for<'b> FnOnce(&'b mut [F::Sample]),
{
let pa_stream = self.pa_stream;
let channels = Writer::channel_count(&self.flow);
let out_buffer = F::writable_buffer(&mut self.mode);
let written_slice = {
let slice = unsafe { out_buffer.slice_mut(frames, channels) };
write_fn(slice);
slice
};
let result = unsafe {
let written_slice_ptr = written_slice.as_ptr() as *mut raw::c_void;
ffi::Pa_WriteStream(pa_stream, written_slice_ptr, frames as raw::c_ulong)
};
match result {
0 => Ok(()),
err => Err(FromPrimitive::from_i32(err).unwrap()),
}
}
This unsound implementation would create memory issues such as overflow, underflow, or misalignment. The attacker can manipulate the argument frames associated with the c_void pointer with a large value, which can lead to an out-of-bounds memory access bug. The c_void pointer and its associated frame count are passed through the FFI (Pa_WriteStream), which can further corrupt the C/C++ code.
This would cause undefined behaviors in Rust. Adversaries can manipulate the associated size argument to cause memory safety bugs. I am reporting this issue for your attention.
Hi, I am scanning this crate in the latest version using my own static analyzer tool.
Unsafe pointer conversion is found at:
This unsound implementation would create memory issues such as overflow, underflow, or misalignment. The attacker can manipulate the argument
framesassociated with thec_voidpointer with a large value, which can lead to an out-of-bounds memory access bug. Thec_voidpointer and its associated frame count are passed through the FFI (Pa_WriteStream), which can further corrupt the C/C++ code.This would cause undefined behaviors in Rust. Adversaries can manipulate the associated size argument to cause memory safety bugs. I am reporting this issue for your attention.