Cloudanix VulnDB

CVE-2023-54033

None

CVSS

—

EPSS

0.2%

Published

Dec 24, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel can cause certain eBPF data structures to leak memory over time, eventually preventing normal operation of programs that depend on them.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Memory leak in BPF LRU and LRU_PERCPU hash map updates: an element is allocated before acquiring the bucket lock, and on lock failure the element is not returned to the free list, leaving it untracked and causing permanent ENOMEM on subsequent updates.

Why it matters to the business

Systems relying on BPF LRU maps may experience unexpected allocation failures that degrade or disrupt eBPF-based networking, security, or observability workloads after prolonged operation.

How an attack unfolds

An attacker with the ability to perform repeated update operations on an LRU BPF map triggers the allocation-without-free path when bucket contention occurs, gradually exhausting available map memory until further updates are rejected.

How to fix it

Upgrade to a kernel containing commit 79ea1a12fb9a8275b6e19d4ca625dd872dedcbb9 or apply the equivalent backport; for affected fixuid packages update to 0.6.0-r1 or later.

How to confirm the fix worked

Confirm the running kernel contains commit 79ea1a12fb9a8275b6e19d4ca625dd872dedcbb9 via version string or source, then exercise LRU map updates under lock contention and verify that ENOMEM no longer occurs after repeated operations.

Typical attack path

  1. Obtain privileges or access sufficient to load and interact with BPF programs using LRU hash maps
  2. Issue repeated map update operations that contend for bucket locks
  3. Trigger the allocation-before-lock sequence under contention to leak elements
  4. Continue until map updates consistently return ENOMEM

How to detect it

Review kernel logs for repeated -ENOMEM returns from BPF map update operations on LRU hash maps; correlate with process activity that frequently calls BPF map updates under high contention.

What your security team should do

  • Prioritize kernel upgrades on systems that load BPF programs using LRU or LRU_PERCPU maps
  • Audit workloads for heavy reliance on LRU maps and schedule maintenance windows accordingly
  • Monitor kernel changelogs for backports of the fix in supported distributions

The record

In the Linux kernel, the following vulnerability has been resolved: bpf: fix a memory leak in the LRU and LRU_PERCPU hash maps The LRU and LRU_PERCPU maps allocate a new element on update before locking the target hash table bucket. Right after that the maps try to lock the bucket. If this fails, then maps return -EBUSY to the caller without releasing the allocated element. This makes the element untracked: it doesn't belong to either of free lists, and it doesn't belong to the hash table, so can't be re-used; this eventually leads to the permanent -ENOMEM on LRU map updates, which is unexpected. Fix this by returning the element to the local free list if bucket locking fails.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 5.11.0 5.15.115

Related vulnerabilities