---
id: RUSTSEC-2026-0253
title: 'Potential use-after-free due to lack of panic safety in `LruCache::pop()`'
summary: 'Potential use-after-free due to lack of panic safety in `LruCache::pop()`'
severity: none
vendor: lru
product: lru
ecosystem: rust
affected:
  - 'lru >= 0.0.0-0, < 0.18.2'
patched:
  - lru 0.18.2
published: '2026-05-12'
updated: '2026-08-11'
source: OSV
sourceUrl: 'https://osv.dev/vulnerability/RUSTSEC-2026-0253'
references:
  - url: 'https://crates.io/crates/lru'
  - url: 'https://rustsec.org/advisories/RUSTSEC-2026-0253.html'
  - url: 'https://github.com/jeromefroe/lru-rs/pull/238'
tags:
  - osv
  - rust
ingestedAt: '2026-08-11T19:17:10.484Z'
---

## Overview

`LruCache::pop()` in `lru` was not panic-safe. If the `Drop` implementation of a stored key panics during `pop()`, `self.detach()` is never called, leaving dangling pointers in the internal doubly-linked list.

A subsequent cache operation that triggers eviction can then dereference these dangling pointers:
- The node is freed from the map, but remains linked in the LRU list due to the skipped `detach()` call
- When a new insertion causes eviction, the LRU traversal encounters the dangling pointer
- This results in a write to already-freed memory during the eviction process

## Impact

- **CWE-416 (Use-After-Free):** memory corruption when subsequent cache operations access freed node pointers in the linked list
- **CWE-415 (Double Free):** potential heap corruption when the same memory is freed multiple times

Both types of undefined behavior can be invoked in safe Rust, but only if unwinding panics are enabled and `std::panic::catch_unwind` is used with key types that have potentially-panicking `Drop` implementations.

## Fix

Fixed in `lru` 0.18.2 by detaching the node from the linked list before freeing it and dropping the key ([lru-rs#238](https://github.com/jeromefroe/lru-rs/pull/238)).

## Affected packages

- `lru >= 0.0.0-0, < 0.18.2`

## Remediation

Upgrade to a patched release:

- `lru 0.18.2`