Fix typos in advisories (#976)

crates/actix-web/RUSTSEC-2018-0019.md

@@ -20,4 +20,4 @@ Affected versions contain multiple memory safety issues, such as:
 
 This may result in a variety of memory corruption scenarios, most likely use-after-free.
  
-A signficant refactoring effort has been conducted to resolve these issues.
+A significant refactoring effort has been conducted to resolve these issues.

crates/bumpalo/RUSTSEC-2020-0006.md

@@ -39,7 +39,7 @@ additional steps:
 2. I've written a quickcheck test to exercise `realloc`. Without the bug fix
    in this patch, this quickcheck immediately triggers invalid reads when run
    under `valgrind`. We didn't previously have quickchecks that exercised
-   `realloc` beacuse `realloc` isn't publicly exposed directly, and instead
+   `realloc` because `realloc` isn't publicly exposed directly, and instead
    can only be indirectly called. This new quickcheck test exercises `realloc`
    via `bumpalo::collections::Vec::resize` and
    `bumpalo::collections::Vec::shrink_to_fit` calls.

crates/claxon/RUSTSEC-2018-0004.md

@@ -21,7 +21,7 @@ allocated and uninitialized, this uninitialized memory could be exposed.
 This allows an attacker to observe parts of the uninitialized memory in the
 decoded audio stream.
 
-The flaw was corrected by checking that the value read from the bistream divides
+The flaw was corrected by checking that the value read from the bitstream divides
 the decode buffer size, and returning a format error if it does not. If an error
 is returned, the decode buffer is not exposed. Regression tests and an
 additional fuzzer have been added to prevent similar flaws in the future.

crates/failure/RUSTSEC-2019-0036.md

@@ -15,7 +15,7 @@ url = "https://github.com/rust-lang-nursery/failure/issues/336"
 patched = []
 ```
 
-# Type confusion if __private_get_type_id__ is overriden
+# Type confusion if __private_get_type_id__ is overridden
 
 Safe Rust code can implement malfunctioning `__private_get_type_id__` and cause
 type confusion when downcasting, which is an undefined behavior.

crates/futures-task/RUSTSEC-2020-0061.md

@@ -19,7 +19,7 @@ Affected versions of the crate used a `UnsafeCell` in thread-local storage to re
 assuming that the reference would never be returned from another thread.
 
 This resulted in a segmentation fault crash if `Waker::wake_by_ref()` was called on a waker returned from another thread due to 
-it attempting to dereference a pointer that wasn't accesible from the main thread.
+it attempting to dereference a pointer that wasn't accessible from the main thread.
 
 Reproduction Example (from issue):
 ```rust

crates/http/RUSTSEC-2019-0033.md

@@ -18,7 +18,7 @@ patched = [">= 0.1.20"]
 # Integer Overflow in HeaderMap::reserve() can cause Denial of Service
 
 `HeaderMap::reserve()` used `usize::next_power_of_two()` to calculate the increased capacity.
-However, `next_power_of_two()` silently overflows to 0 if given a sufficently large number
+However, `next_power_of_two()` silently overflows to 0 if given a sufficiently large number
 in release mode.
 
 If the map was not empty when the overflow happens,

crates/hyper/RUSTSEC-2021-0078.md

@@ -14,7 +14,7 @@ patched = [">= 0.14.10"]
 # Lenient `hyper` header parsing of `Content-Length` could allow request smuggling
 
 `hyper`'s HTTP header parser accepted, according to RFC 7230, illegal contents inside `Content-Length` headers.
-Due to this, upstream HTTP proxies that ignore the the header may still forward them along if it chooses to ignore the error.
+Due to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error.
 
 To be vulnerable, `hyper` must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents
-but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerablity is unlikely.
+but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.

crates/lettre/RUSTSEC-2020-0069.md

@@ -26,7 +26,7 @@ to the sendmail command. It was possible, using forged `to` addresses,
 to pass arbitrary arguments to the sendmail executable.
 
 Depending on the implementation (original sendmail, postfix, exim, etc.)
-it could be possible in some cases to write email data into abritrary files (using sendmail's
+it could be possible in some cases to write email data into arbitrary files (using sendmail's
 logging features).
  
 The flaw is corrected by modifying the executed command to stop parsing arguments

crates/mozwire/RUSTSEC-2020-0030.md

@@ -19,6 +19,6 @@ after the hostname field in the json document.
 
 No verification of the content of the string was made, and it could therefore have included '../' leading to path traversal.
 
-This allows an attacker in controll of mozilla's servers to overwrite/create local files named .conf.
+This allows an attacker in control of mozilla's servers to overwrite/create local files named .conf.
 
 The flaw was corrected by sanitizing the hostname field.

crates/net2/RUSTSEC-2020-0078.md

@@ -16,7 +16,7 @@ patched = [">= 0.2.36"]
 
 The [`net2`](https://crates.io/crates/net2) crate has assumed `std::net::SocketAddrV4`
 and `std::net::SocketAddrV6` have the same memory layout as the system C representation
-`sockaddr`. It has simply casted the pointers to convert the socket addresess to the
+`sockaddr`. It has simply casted the pointers to convert the socket addresses to the
 system representation. The standard library does not say anything about the memory
 layout, and this will cause invalid memory access if the standard library
 changes the implementation. No warnings or errors will be emitted once the

crates/once_cell/RUSTSEC-2019-0017.md

@@ -21,7 +21,7 @@ unaffected = ["< 0.2.5"]
 # Panic during initialization of Lazy<T> might trigger undefined behavior
 
 If during the first dereference of Lazy<T> the initialization function panics,
-subsequent derefernces will execute `std::hints::unreachable_unchecked`.
+subsequent dereferences will execute `std::hints::unreachable_unchecked`.
 
 Applications with `panic = "abort"` are not affected, as there will be no
 subsequent dereferences.

crates/raw-cpuid/RUSTSEC-2021-0013.md

@@ -47,4 +47,4 @@ to crash deterministically every time.
 See https://github.com/gz/rust-cpuid/issues/41.
 
 The flaw has been fixed in v9.0.0, by intentionally breaking compilation
-when targetting SGX or 32-bit x86 without SSE. This covers all affected CPUs.
+when targeting SGX or 32-bit x86 without SSE. This covers all affected CPUs.

crates/trust-dns-server/RUSTSEC-2020-0001.md

@@ -13,7 +13,7 @@ patched = [">= 0.18.1"]
 unaffected = ["< 0.16.0"]
 ```
 
-# Stack overflow when resolving addional records from MX or SRV null targets
+# Stack overflow when resolving additional records from MX or SRV null targets
 
 There's a stack overflow leading to a crash and potential DOS when processing
 additional records for return of MX or SRV record types from the server.

rust/std/CVE-2021-29922.md

@@ -24,6 +24,6 @@ IP address octects are left stripped instead of evaluated as valid IP addresses.
 For example, an attacker submitting an IP address to a web application that relies on `std::net::IpAddr`,
 could cause SSRF via inputting octal input data;
 An attacker can submit exploitable IP addresses if the octet is 3 digits,
-with the minimum exploitable octect being 08 (Denial of Service) and the maximum exploitable octet is 099 (Denial of Service).
+with the minimum exploitable octet being 08 (Denial of Service) and the maximum exploitable octet is 099 (Denial of Service).
 For example, an attacker can submit `010.8.8.8`, which is `8.8.8.8` (RFI), yet `std::net::IpAddr` will evaluate this as `10.8.8.8`.
 Equally, an attacker can input `127.0.026.1` which is really `127.0.22.1` but rust evaluates it as `127.0.26.1`.