CVE-2020-36216

An attacker who controls code that uses the eventio crate can construct an `Input<R>` wrapping a `Read` implementation that contains a non-`Send` (and non-`Sync`) object, such as `Rc<Cell<usize>>` [ref_id=1]. Because `Input<R>` unconditionally implements `Send`, this object can be moved to multiple threads. Multiple threads then concurrently call `read()` on the same non-`Sync` object, producing a data race and memory corruption [CWE-662] [CWE-787]. The proof of concept demonstrates this by spawning 8 threads that each run `input.run()` on an `Input` sharing the same `Rc<Cell<usize>>`, causing the `Cell` to hold an incorrect count [ref_id=1].

The vulnerability is in the `Input<R>` struct in the eventio crate (before version 0.5.1). The unsafe `Send` implementation at `src/pcap.rs:22:1: 22:55` unconditionally implements `Send` for `Input<R>` without requiring `R: Send` [ref_id=1]. This allows a non-`Send` type (such as `Rc<Cell<usize>>`) to be sent across threads inside `Input<R>`.

The fix adds the trait bound `R: Send` to the unsafe `Send` implementation for `Input<R>`, changing it from `unsafe impl<R: Read> Send for Input<R> {}` to `unsafe impl<R: Read + Send> Send for Input<R> {}` [ref_id=1]. This ensures the compiler rejects any attempt to send an `Input<R>` to another thread when `R` is not `Send`, preventing the data race at compile time. No patch file is included in the bundle, but the suggested solution from the advisory is the authoritative remediation guidance [ref_id=1].

Use the proof-of-concept program provided in the advisory [ref_id=1]. Compile and run the Rust program that creates a `CustomRead` containing an `Rc<Cell<usize>>`, wraps it in `pcap::Input::with_read`, spawns 8 threads each calling `input.run()`, and then asserts that the atomic counter matches the `Cell` counter — the assertion fails because the `Cell` is corrupted by concurrent access across threads.