fix(deps): update rust crate linked_list_allocator to 0.10.0 [security]

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
linked_list_allocator (source)	dependencies	minor	0.9.0 -> 0.10.0

GitHub Vulnerability Alerts

CVE-2022-36086

Impact

What kind of vulnerability is it? Who is impacted?

This vulnerability impacts all the initialization functions on the Heap and LockedHeap types, including Heap::new, Heap::init, Heap::init_from_slice, and LockedHeap::new. It also affects multiple uses of the Heap::extend method.

Initialization Functions

The heap initialization methods were missing a minimum size check for the given heap size argument. This could lead to out-of-bound writes when a heap was initialized with a size smaller than 3 * size_of::<usize> because of metadata write operations.

Heap::extend

This vulnerability impacts three specific uses of the Heap::extend method:

• When calling Heap::extend with a size smaller than two usizes (e.g., 16 on x86_64), the size was erroneously rounded up to the minimum size, which could result in an out-of-bounds write.
• Calling Heap::extend on an empty heap tried to construct a heap starting at address 0, which is also an out-of-bounds write.
  • One specific way to trigger this accidentally is to call Heap::new (or a similar constructor) with a heap size that is smaller than two usizes. This was treated as an empty heap as well.
• Calling Heap::extend on a heap whose size is not a multiple of the size of two usizes resulted in unaligned writes. It also left the heap in an unexpected state, which might lead to subsequent issues. We did not find a way to exploit this undefined behavior yet (apart from DoS on platforms that fault on unaligned writes).

Patches

Has the problem been patched? What versions should users upgrade to?

We published a patch in version 0.10.2 and recommend all users to upgrade to it. This patch release includes the following changes:

• The initialization functions now panic if the given size is not large enough to store the necessary metadata. Depending on the alignment of the heap bottom pointer, the minimum size is between 2 * size_of::<usize> and 3 * size_of::<usize>.
• The extend method now panics when trying to extend an unitialized heap.
• Extend calls with a size smaller than size_of::<usize>() * 2 are now buffered internally and not added to the list directly. The buffered region will be merged with future extend calls.
• The size() method now returns the usable size of the heap, which might be slightly smaller than the top() - bottom() difference because of alignment constraints.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

To avoid this issue, ensure that the heap is only initialized with a size larger than 3 * size_of::<usize> and that the Heap::extend method is only called with sizes larger than 2 * size_of::<usize>(). Also, ensure that the total heap size is (and stays) a multiple of 2 * size_of::<usize>().

For more information

If you have any questions or comments about this advisory:

• Open an issue in this repository
• Email @​phil-opp at [email protected]

Acknowledgements

This issue was responsibly reported by Evan Richter at ForAllSecure and found with Mayhem and cargo fuzz.

---

Release Notes

phil-opp/linked-list-allocator (linked_list_allocator)

v0.10.2

Compare Source

Fix for potential out-of-bound writes that were possible on Heap initialization and Heap::extend. See the security advisory for details. The issues were fixed in the following way:

• The initialization functions now panic if the given size is not large enough to store the necessary metadata. Depending on the alignment of the heap bottom pointer, the minimum size is between 2 * size_of::<usize> and 3 * size_of::<usize>.
• The extend method now panics when trying to extend an unitialized heap.
• Extend calls with a size smaller than size_of::<usize>() * 2 are now buffered internally and not added to the list directly. The buffered region will be merged with future extend calls.
• The size() method now returns the usable size of the heap, which might be slightly smaller than the top() - bottom() difference because of alignment constraints.

v0.10.1

Compare Source

• Fixed logic for freeing nodes (#​64)

v0.10.0

Compare Source

• Changed constructor to take *mut u8 instead of usize (#​62)
  • NOTE: Breaking API change
• Reworked internals to pass Miri tests (#​62)

---

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

• any of the package files in this branch needs updating, or
• the branch becomes conflicted, or
• you click the rebase/retry checkbox if found above, or
• you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: Cargo.lock

Command failed: cargo update --config net.git-fetch-with-cli=true --manifest-path Cargo.toml --package [email protected] --precise 0.10.2
error: failed to acquire package cache lock

Caused by:
  failed to open: /home/ubuntu/.cargo/.package-cache

Caused by:
  failed to create directory `/home/ubuntu/.cargo`

Caused by:
  File exists (os error 17)