diff --git a/library/alloc/src/slice.rs b/library/alloc/src/slice.rs
index 79540fcd395..846f8ba6c6e 100644
--- a/library/alloc/src/slice.rs
+++ b/library/alloc/src/slice.rs
@@ -193,7 +193,7 @@ impl<T> [T] {
     /// The current implementation is based on [driftsort] by Orson Peters and Lukas Bergdoll, which
     /// combines the fast average case of quicksort with the fast worst case and partial run
     /// detection of mergesort, achieving linear time on fully sorted and reversed inputs. On inputs
-    /// with k distinct elements, the expected time to sort the data is *O(*n* log(*k*))*.
+    /// with k distinct elements, the expected time to sort the data is *O(*n* \* log(*k*))*.
     ///
     /// The auxiliary memory allocation behavior depends on the input length. Short slices are
     /// handled without allocation, medium sized slices allocate `self.len()` and beyond that it
@@ -252,7 +252,7 @@ pub fn sort(&mut self)
     /// The current implementation is based on [driftsort] by Orson Peters and Lukas Bergdoll, which
     /// combines the fast average case of quicksort with the fast worst case and partial run
     /// detection of mergesort, achieving linear time on fully sorted and reversed inputs. On inputs
-    /// with k distinct elements, the expected time to sort the data is *O(*n* log(*k*))*.
+    /// with k distinct elements, the expected time to sort the data is *O(*n* \* log(*k*))*.
     ///
     /// The auxiliary memory allocation behavior depends on the input length. Short slices are
     /// handled without allocation, medium sized slices allocate `self.len()` and beyond that it
@@ -298,7 +298,7 @@ pub fn sort_by<F>(&mut self, mut compare: F)
     /// The current implementation is based on [driftsort] by Orson Peters and Lukas Bergdoll, which
     /// combines the fast average case of quicksort with the fast worst case and partial run
     /// detection of mergesort, achieving linear time on fully sorted and reversed inputs. On inputs
-    /// with k distinct elements, the expected time to sort the data is *O(*n* log(*k*))*.
+    /// with k distinct elements, the expected time to sort the data is *O(*n* \* log(*k*))*.
     ///
     /// The auxiliary memory allocation behavior depends on the input length. Short slices are
     /// handled without allocation, medium sized slices allocate `self.len()` and beyond that it
diff --git a/library/core/src/slice/mod.rs b/library/core/src/slice/mod.rs
index 4e6070cdb1b..3c818eacca3 100644
--- a/library/core/src/slice/mod.rs
+++ b/library/core/src/slice/mod.rs
@@ -2893,7 +2893,7 @@ pub fn binary_search_by_key<'a, B, F>(&'a self, b: &B, mut f: F) -> Result<usize
     /// The current implementation is based on [ipnsort] by Lukas Bergdoll and Orson Peters, which
     /// combines the fast average case of quicksort with the fast worst case of heapsort, achieving
     /// linear time on fully sorted and reversed inputs. On inputs with k distinct elements, the
-    /// expected time to sort the data is *O(*n* log(*k*))*.
+    /// expected time to sort the data is *O(*n* \* log(*k*))*.
     ///
     /// It is typically faster than stable sorting, except in a few special cases, e.g., when the
     /// slice is partially sorted.
@@ -2950,7 +2950,7 @@ pub fn sort_unstable(&mut self)
     /// The current implementation is based on [ipnsort] by Lukas Bergdoll and Orson Peters, which
     /// combines the fast average case of quicksort with the fast worst case of heapsort, achieving
     /// linear time on fully sorted and reversed inputs. On inputs with k distinct elements, the
-    /// expected time to sort the data is *O(*n* log(*k*))*.
+    /// expected time to sort the data is *O(*n* \* log(*k*))*.
     ///
     /// It is typically faster than stable sorting, except in a few special cases, e.g., when the
     /// slice is partially sorted.
@@ -2994,7 +2994,7 @@ pub fn sort_unstable_by<F>(&mut self, mut compare: F)
     /// The current implementation is based on [ipnsort] by Lukas Bergdoll and Orson Peters, which
     /// combines the fast average case of quicksort with the fast worst case of heapsort, achieving
     /// linear time on fully sorted and reversed inputs. On inputs with k distinct elements, the
-    /// expected time to sort the data is *O(*n* log(*k*))*.
+    /// expected time to sort the data is *O(*n* \* log(*k*))*.
     ///
     /// It is typically faster than stable sorting, except in a few special cases, e.g., when the
     /// slice is partially sorted.
@@ -3042,8 +3042,8 @@ pub fn sort_unstable_by_key<K, F>(&mut self, mut f: F)
     /// Median of Medians using Tukey's Ninther for pivot selection, which guarantees linear runtime
     /// for all inputs.
     ///
-    /// It is typically faster than sorting, except in a few special cases, e.g., when the slice is
-    /// nearly fully sorted, where [`slice::sort`] may be faster.
+    /// It is typically faster than stable sorting, except in a few special cases, e.g., when the
+    /// slice is nearly fully sorted, where `slice::sort` may be faster.
     ///
     /// [`sort_unstable`]: slice::sort_unstable
     ///
@@ -3103,8 +3103,8 @@ pub fn select_nth_unstable(&mut self, index: usize) -> (&mut [T], &mut T, &mut [
     /// Median of Medians using Tukey's Ninther for pivot selection, which guarantees linear runtime
     /// for all inputs.
     ///
-    /// It is typically faster than sorting, except in a few special cases, e.g., when the slice is
-    /// nearly fully sorted, where [`slice::sort`] may be faster.
+    /// It is typically faster than stable sorting, except in a few special cases, e.g., when the
+    /// slice is nearly fully sorted, where `slice::sort` may be faster.
     ///
     /// [`sort_unstable`]: slice::sort_unstable
     ///
@@ -3168,8 +3168,8 @@ pub fn select_nth_unstable_by<F>(
     /// Median of Medians using Tukey's Ninther for pivot selection, which guarantees linear runtime
     /// for all inputs.
     ///
-    /// It is typically faster than sorting, except in a few special cases, e.g., when the slice is
-    /// nearly fully sorted, where [`slice::sort`] may be faster.
+    /// It is typically faster than stable sorting, except in a few special cases, e.g., when the
+    /// slice is nearly fully sorted, where `slice::sort` may be faster.
     ///
     /// [`sort_unstable`]: slice::sort_unstable
     ///