Here's a list of issues in the Unsafe Deep Dive chapter which I don't feel confident to fix myself:

• The may_overflow section in the introduction is incorrect. Arithmetic overflow as in 1 + i32::MAX is not undefined behavior. It is well defined to either panic or wrap-around at the implementation's discretion.
• There seems to be a leftover sentence in the "Arrays of uninit" section, namely the one about slice_assume_init_ref. It says the example uses &buf[..input.len()] while it doesn't.
• The pinning chapter contains an empty "details" in the speaker notes.
• The "What pinning is" section contains an unfinished sentence before the speaker notes, namely "This is explained in".
• In the same section, the sentence "A “pointer type” wraps every type that implements Deref with a target that implements Unpin." seems wrong. It's too imprecise to actually refute, but Unpin should not be a concern in this sentence.
• The outline in the "Self-Referential Buffer Example" section is wrong. It's the one of the pinning chapter.
• The "With a raw pointer" section states "unsafe blocks lack of safety comments. Therefore, this code is unsound." which is wrong. This Unsafe Deep Dive chapter uses the terminology "not safe" for unsafe blocks without safety comments. The terminology "unsound" means it is possible to trigger UB while satisfying safety preconditions.
• In the same section, the answer is insufficient. The fact that the object can move should be addressed. It should be mentioned that in that case, either cursor will point outside the expected data range (for non-overlapping moves) or it will still point inside but at a possibly incorrect position. In both cases, the rest of the function is sound due to this assertion.
• The "With Pin" section feels unsatisfying. The unsafe blocks are still very large and the pinning guarantee is not used. The assertions are still there.
• The "Pin and Drop" section provides a confusing example for an incorrect drop implementation. I would expect something like mem::take(&mut self.data) instead of ptr::read(&self.data). And even then, it's arguable how bad that would be since self.ptr is not used afterwards and the whole object is at its lifetime end.