WakerRef depends on libstd implementation detail for soundness

[bjorn3]

It depends on the fact that Waker always stores the data of the waker behind a reference and never inline. If data was stored inline, WakerRef could be used to cause a use after free by storing a Mutex<Vec<u8>> in the waker and then for a WakerRef derived from this waker mutate it to force the vec to reallocate and then access the vec stored in the original waker, which is now dangling due to WakerRef storing a copy of the waker rather than a reference.

[taiki-e]

Hmm, RawWaker docs say it consisted of a pointer and a vtable, so I thought it would never inline the data...

[bjorn3]

It doesn't right now, that is why it is sound right now. I don't think it gives any guarantees it will never inline the data, which is why it relies on an implementation detail for soundness. Either WakerRef could be changed, or the docs of RawWaker could be changed to explicitly allow this.

[carbotaniuman]

The API of RawWaker doesn't allow the data to be stored inline (const ()), so I don't think this is an actual issue.

[bjorn3]

The current API doesn't and that is why it is fine right now. There is no guarantee that this will remain the same in the future. It makes sense that it will remain the same, but it isn't documented as such.