mopa is technically unsound (#927)

* Added the mopa vulnerability

* Update crates/mopa/RUSTSEC-0000-0000.md

Co-authored-by: Tony Arcieri <bascule@gmail.com>

crates/mopa/RUSTSEC-0000-0000.md

@@ -0,0 +1,32 @@
+```toml
+[advisory]
+id = "RUSTSEC-0000-0000"
+package = "mopa"
+date = "2021-06-01"
+url = "https://github.com/chris-morgan/mopa/issues/13"
+categories = ["memory-corruption", "memory-exposure", "code-execution"]
+keywords = ["transmute", "dyn"]
+informational = "unsound"
+
+[versions]
+patched = []
+```
+
+# `mopa` is technically unsound
+The `mopa` crate redefines the deprecated `TraitObject` struct from `core::raw` like so:
+```rust
+#[repr(C)]
+#[derive(Copy, Clone)]
+#[doc(hidden)]
+pub struct TraitObject {
+    pub data: *mut (),
+    pub vtable: *mut (),
+}
+```
+This is done to then transmute a reference to a trait object (`&dyn Trait` for any trait `Trait`) into this struct and retrieve the `data` field for the purpose of downcasting. This is used to implement `downcast_ref_unchecked()`, in terms of which `downcast_ref()` is also implemented. Same goes for mutable reference downcasting and `Box` downcasting.
+
+The Rust compiler explicitly reserves the right to change the memory layout of `&dyn Trait` for any trait `Trait`. The worst case scenario is that it swaps `data` and `vtable`, making an executable location breach and compromisation of ASLR possible, since reads from `data` would read `vtable` instead. Likewise, arbitrary code execution is also theoretically possible if reads of `vtable` generated by the compiler read `data` instead.
+
+While, as of Rust 1.52, this unsound assumption still holds true, updating the compiler may silently create UB in a crate which previously compiled and run without issues, compromising the security of builds which are believed to be reproducible.
+
+A potential strategy to resolve this has already been suggested in an issue on the GitHub repository of the crate.