Cloudanix VulnDB

CVE-2023-53481

None

CVSS

—

EPSS

0.2%

Published

Oct 1, 2025

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A flaw in Linux flash storage handling can make a kernel task run forever and freeze the system until the software is updated.

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

What it actually does

Infinite loop in ubi_wl_put_peb due to NULL comparison after wl_entry_destroy removes entry from lookuptbl during wear_leveling_worker error path; additional wl_lock missing allows use-after-free on wl entry.

Why it matters to the business

Kernel background thread spins at 100% CPU causing system unresponsiveness; requires kernel update to restore normal flash wear-leveling operation on affected Linux deployments.

How an attack unfolds

Attacker or workload triggers ubifs_leb_unmap while wear_leveling_worker encounters flash read error on vid header; this clears move_from/move_to, destroys entry, and leaves put_peb retrying on NULL lookup causing endless loop.

How to fix it

Update to fixed kernel commit b40d2fbf47af58377e898b5062077a47bb28a132 or Debian DPDK packages 19.11.5-1 and later; rebuild and reboot with patched kernel to eliminate the retry condition and add wl_lock protection.

How to confirm the fix worked

Confirm kernel version contains commit b40d2fbf47af58377e898b5062077a47bb28a132; run targeted UBI wear-leveling stress tests that previously reproduced the loop and verify no 100% CPU spin on ubifs_bgt threads.

Typical attack path

  1. Trigger UBI/UBIFS unmap operation from userspace or filesystem activity
  2. Induce or wait for wear_leveling_worker to hit flash fault on vid header read
  3. Observe entry removal from lookuptbl without proper locking
  4. ubi_wl_put_peb enters retry loop comparing against NULL move_from

How to detect it

Search kernel logs and process accounting for sustained 100% CPU on ubifs_bgt threads coinciding with UBI wear-leveling errors or flash faults; inspect for repeated ubi_wl_put_peb retry messages if debug logging enabled.

  • ubifs_bgt.*100.0.*R
  • ubi_wl_put_peb retry loop
  • wear_leveling_worker.*ubi_io_read_vid_hdr.*err

What your security team should do

  • Prioritize kernel upgrade on all systems using UBI/UBIFS flash storage within patch window
  • Monitor for high CPU usage on ubifs_bgt threads as temporary indicator of exposure
  • Apply updated Debian packages for dpdk where UBI-dependent workloads exist

The record

In the Linux kernel, the following vulnerability has been resolved: ubi: ubi_wl_put_peb: Fix infinite loop when wear-leveling work failed Following process will trigger an infinite loop in ubi_wl_put_peb(): ubifs_bgt ubi_bgt ubifs_leb_unmap ubi_leb_unmap ubi_eba_unmap_leb ubi_wl_put_peb wear_leveling_worker e1 = rb_entry(rb_first(&ubi->used) e2 = get_peb_for_wl(ubi) ubi_io_read_vid_hdr // return err (flash fault) out_error: ubi->move_from = ubi->move_to = NULL wl_entry_destroy(ubi, e1) ubi->lookuptbl[e->pnum] = NULL retry: e = ubi->lookuptbl[pnum]; // return NULL if (e == ubi->move_from) { // NULL == NULL gets true goto retry; // infinite loop !!! $ top PID USER PR NI VIRT RES SHR S %CPU %MEM COMMAND 7676 root 20 0 0 0 0 R 100.0 0.0 ubifs_bgt0_0 Fix it by: 1) Letting ubi_wl_put_peb() returns directly if wearl leveling entry has been removed from 'ubi->lookuptbl'. 2) Using 'ubi->wl_lock' protecting wl entry deletion to preventing an use-after-free problem for wl entry in ubi_wl_put_peb(). Fetch a reproducer in [Link].

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 2.6.25 4.14.308

Related vulnerabilities