Cloudanix VulnDB

CVE-2023-53826

None

CVSS

—

EPSS

0.3%

Published

Dec 9, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux storage handling could let a local attacker cause crashes or potentially run code by racing two internal operations that access the same memory after it has been freed.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in the UBI wear-leveling subsystem where a wl_entry can be freed via wl_entry_destroy while eraseblk_count_seq_show still holds a reference obtained from ubi->lookuptbl without holding ubi->wl_lock, allowing subsequent access to the freed structure.

Why it matters to the business

Potential kernel instability, crashes, or local privilege escalation on systems using UBI flash storage; low immediate risk given age and lack of known exploitation but still requires patching to maintain kernel integrity.

How an attack unfolds

An attacker with local access triggers concurrent wear-leveling operations and seq_file reads on /proc or debugfs UBI interfaces so that wl_entry_destroy nulls and frees the entry while eraseblk_count_seq_show dereferences it, leading to a use-after-free read.

How to fix it

Update to a kernel containing commit 3f9b63dfce44a7c3c095dd93d910408e07ab1845 or later; rebuild and reboot. For Ubuntu 14.04 LTS and 16.04 LTS environments using the listed rsync packages, apply the corresponding fixed package versions 3.1.0-2ubuntu0.4 or 3.1.1-3ubuntu1.2 respectively and verify the kernel update is also present.

How to confirm the fix worked

Confirm the patch is applied by checking for the wl_lock serialization around lookuptbl access in eraseblk_count_seq_show and wl_entry_destroy; run the linked reproducer in a test environment and verify it no longer triggers the UAF.

Typical attack path

  1. Obtain local shell on a UBI-enabled Linux system
  2. Trigger parallel erase worker activity and seq_file reads on UBI wear-leveling data
  3. Race wl_entry_destroy against eraseblk_count_seq_show to hit the freed pointer
  4. Use resulting UAF read for information leak or to corrupt kernel structures

How to detect it

Inspect kernel logs for UBI wear-leveling warnings, slab UAF reports, or oops involving eraseblk_count_seq_show or wl_entry_destroy; correlate with process activity opening UBI seq files around the same time.

What your security team should do

  • Prioritize kernel updates on all UBI-using systems within standard patch windows
  • Audit for UBI usage in embedded or flash-based deployments
  • Add kernel UAF and UBI seq_file monitoring to existing detection rules
  • Review and restrict unprivileged access to UBI debug interfaces where feasible

The record

In the Linux kernel, the following vulnerability has been resolved: ubi: Fix UAF wear-leveling entry in eraseblk_count_seq_show() Wear-leveling entry could be freed in error path, which may be accessed again in eraseblk_count_seq_show(), for example: __erase_worker eraseblk_count_seq_show wl = ubi->lookuptbl[*block_number] if (wl) wl_entry_destroy ubi->lookuptbl[e->pnum] = NULL kmem_cache_free(ubi_wl_entry_slab, e) erase_count = wl->ec // UAF! Wear-leveling entry updating/accessing in ubi->lookuptbl should be protected by ubi->wl_lock, fix it by adding ubi->wl_lock to serialize wl entry accessing between wl_entry_destroy() and eraseblk_count_seq_show(). Fetch a reproducer in [Link].

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 2.6.22 4.14.308

Related vulnerabilities