diff --git a/crates/lock_api/RUSTSEC-0000-0000.md b/crates/lock_api/RUSTSEC-0000-0000.md
new file mode 100644
index 0000000000..9c84b713c8
--- /dev/null
+++ b/crates/lock_api/RUSTSEC-0000-0000.md
@@ -0,0 +1,39 @@
+```toml
+[advisory]
+id = "RUSTSEC-0000-0000"
+package = "lock_api"
+date = "2020-11-08"
+url = "https://github.com/Amanieu/parking_lot/pull/262"
+categories = ["memory-corruption"]
+keywords = ["concurrency"]
+informational = "unsound"
+
+[versions]
+patched = [">= 0.4.2"]
+
+[affected]
+functions = {
+    "lock_api::MappedMutexGuard" = [">= 0.1.0"]
+    "lock_api::MappedRwLockReadGuard" = [">= 0.1.0"]
+    "lock_api::MappedRwLockWriteGuard" = [">= 0.1.0"]
+    "lock_api::RwLockReadGuard" = [">= 0.1.0"]
+    "lock_api::RwLockWriteGuard" = [">= 0.1.0"]
+}
+```
+
+# Some lock_api lock guard objects can cause data races
+
+Affected versions of lock_api had unsound implementations of the `Send` or
+`Sync` traits for some guard objects, namely:
+
+* MappedMutexGuard
+* MappedRwLockReadGuard
+* MappedRwLockWriteGuard
+* RwLockReadGuard
+* RwLockWriteGuard
+
+These guards could allow data races through types that are not safe to `Send`
+across thread boundaries in safe Rust code.
+
+This issue was fixed by changing the trait bounds on the `Mapped` guard types
+and removing the `Sync` trait for the `RwLock` guards.