recvmsg: incorrect lifetime returned

[yuval-k]

the current signature of recvmsg is:

pub fn recvmsg<'a, 'outer, 'inner, S>(fd: RawFd, iov: &'outer mut [IoSliceMut<'inner>],
                   mut cmsg_buffer: Option<&'a mut Vec<u8>>,
                   flags: MsgFlags) -> Result<RecvMsg<'a, 'inner, S>>

note the iov param: iov: &'outer mut [IoSliceMut<'inner>]

now in the resulting RecvMsg we can access the iovs using a method named iovs(). This method iterates the iov array provided. But the lifetime of the iov array is 'outer and not 'inner.

So the signature of the result should be changed to Result<RecvMsg<'a, 'outer, S>>.

If all sounds correct, i can open a PR to fix this.

example fail scenario with tokio (note the move closure):

            let tokio_stream = /* get a stream somehow... */;
            let mut buffer = vec![0u8; 10];

            let mut iov = [IoSliceMut::new(&mut buffer)];
            
            let res: Result<nix::sys::socket::RecvMsg<'_, '_, ()>, std::io::Error> =
                tokio_stream.try_io(tokio::io::Interest::READABLE, move || {
                    recvmsg::<()>(
                        raw_fd,
                        &mut iov,
                        None,
                        MsgFlags::empty(),
                    )
                    .map_err(|e| std::io::Error::from_raw_os_error(e as i32))
                });
            match res {
                Ok(res) => {
// BUG HAPPENS HERE
// NOTE: here res.iovs() uses the iov array that was moved in the try_io closure
// res.iovs() may point to invalid memory, as iov may have been destroyed already.
                }
                Err(e) => { /* ... */  }
            };
    }

[asomers]

Yes, I think your analysis is correct. Would you submit a PR?

[yuval-k]

I can but I'm not available to do it this week. I can submit one next week. Please feel free to fix if you require this sooner.

[cgwalters]

Good catch on this! Looks like one of my projects was affected containers/containers-image-proxy-rs#52

I guess any potentially problematic code will now fail to compile, which is good. I wonder if this could use a bit more visibility though with e.g. a rustsec advisory?

[cgwalters]

Using a GH code search I'm seeing a few other repositories likely affected too.

• stratis (edit: opened an issue)
• runa
• breadx
• clipper
• garage
• adrastea