---
id: RUSTSEC-2026-0291
title: >-
  Double free in `OwnedAlloc::drop_in_place` when the contained value's `Drop`
  panics
summary: >-
  Double free in `OwnedAlloc::drop_in_place` when the contained value's `Drop`
  panics
severity: none
vendor: owned-alloc
product: owned-alloc
ecosystem: rust
affected:
  - owned-alloc >= 0.0.0-0
published: '2026-09-09'
updated: '2026-09-21'
sourceUpdated: '2026-09-21T09:15:02.893165285Z'
source: OSV
sourceUrl: 'https://osv.dev/vulnerability/RUSTSEC-2026-0291'
references:
  - url: 'https://crates.io/crates/owned-alloc'
  - url: 'https://rustsec.org/advisories/RUSTSEC-2026-0291.html'
  - url: 'https://gitlab.com/bzim/owned-alloc/-/issues/1'
tags:
  - osv
  - rust
ingestedAt: '2026-09-21T16:06:16.785Z'
---

## Overview

`OwnedAlloc::drop_in_place` destroys the contained value by hand, then commits
the ownership transfer with `mem::forget(self)` — which lives inside `into_raw`
and so runs only after the destruction. `T::drop` is user code and may panic. If
it does, the forget is skipped and the still-live `OwnedAlloc` unwinds, whose
destructor drops the same `T` a second time and then deallocates. For a `T` that
owns an allocation, the same block is freed twice — a double free (CWE-415).
That destructor also reads the already-destroyed value through
`Layout::for_value` before deallocating, a use-after-free (CWE-416).

`MaybeUninitAlloc::drop_in_place` delegates to the same function, so both public
entry points are affected. Storing a value whose `Drop` can panic and calling
either is enough — no `unsafe` on the caller's side.

## Fix

No fixed release is available. The crate has had no release since 2018 and the
maintainer has not responded to the report, nor to the one on `lockfree`, which
is published from the same account. `forget_inner` leaks the value instead of
destroying it, which is safe.

## Affected packages

- `owned-alloc >= 0.0.0-0`

## Remediation

Refer to the advisory for the patched release.