xcb connect_to_fd* constructors unsound

[En-En-Code]

Identifies a flaw in xcb::Connection::connect_to_fd and xcb::Connection::connect_to_fd_with_extensions which allows file descriptors to be used after close and/or double closed. An issue was raised back in 2022 to mark these functions as unsafe with no additional context. I discovered this unsoundness causing problems working on a different project and reported my findings to xcb.
It is unclear as to whether the project is maintained, though previously there was an issue raised as to its maintained status (see #653).
I did not put any categories or keywords. I just did not know what to put for them.

[djc]

I've emailed @rtbo personally (they seem somewhat active on GitHub at least), let's see if they respond in the next two weeks. If not, we should go ahead and merge the advisory (please help remind me).

[rtbo]

Hi,
I've honestly little time to allocate to the maintenance of rust-xcb, but I don't want it to die unmaintained either!
I can definitely share a write access to the repo.

[fintelia]

One thing to mention is that this isn't a memory safety violation but rather an I/O safety violation. I think that may warrant tagging it with a dedicated category? It also wasn't clear to me from reading the discussions linked from that RFC whether I/O safety violations can cause undefined behavior, and thus whether this qualifies as "unsound" at all.

I also experimented with the nix crate a bit and discovered that you can trigger the same crash described here simply by opening a file with File::open, getting its raw file descriptor via as_raw_fd, and then closing it with both the (safe) nix::unistd::close file and via dropping the File. If this really constitutes undefined behavior... I feel like a crate as widely used as nix would've been fixed already?

[rtbo]

Should be closed by rust-x-bindings/rust-xcb#283

[djc]

One thing to mention is that this isn't a memory safety violation but rather an I/O safety violation. I think that may warrant tagging it with a dedicated category? It also wasn't clear to me from reading the discussions linked from that RFC whether I/O safety violations can cause undefined behavior, and thus whether this qualifies as "unsound" at all.

That's a good point, this probably doesn't qualify as unsound.