CVE-2023-53481: ubi: ubi_wl_put_peb: Fix infinite loop when wear-leveling work failed
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].
Security readout for executives and security teams
Plain-English summary
A Linux UBI flash-management flaw can trap a kernel background thread in an endless loop after a flash read failure, consuming 100% CPU. The correction also addresses unsafe concurrent memory handling. Systems using UBI/UBIFS may suffer disruption; however, the supplied evidence does not establish real-world compromise or active exploitation.
Executive priority
Treat this as an expedited maintenance issue for flash-based Linux appliances, especially operationally critical or remotely managed fleets. It is not supported as an internet-wide emergency because exploitation requires local access and no active exploitation is documented. Unclear version metadata makes asset-specific verification important.
Technical view
After the wear-leveling worker deletes an entry, ubi_wl_put_peb() can retrieve NULL and incorrectly treat it as matching the NULL move_from pointer, retrying indefinitely. The stable fix returns when the lookup entry is absent and uses wl_lock during deletion to prevent a potential use-after-free race.
Likely exposure
Exposure is concentrated in Linux devices using UBI/UBIFS on flash storage. The record identifies versions from 2.6.25 through 6.3, including several stable-series endpoints, but its version structure is ambiguous. Confirm exposure through kernel package provenance, commit ancestry, and downstream vendor guidance rather than version strings alone.
Exploitation context
The CVSS 3.1 vector scores this 7.8 and requires local access with low privileges and no user interaction. The supplied record is not in KEV and contains no evidence of active exploitation. A reproducer is mentioned, but the bundle does not provide its link or demonstrate weaponized exploitation.
Researcher notes
Eight Linux stable commits are cited as backports. The demonstrated failure is an infinite retry loop, while the locking change explicitly prevents a possible use-after-free. Although CVSS claims high confidentiality, integrity, and availability impacts, the narrative directly demonstrates CPU exhaustion and does not establish code execution or data compromise. No CWE is assigned.
Mitigation direction
Upgrade to a vendor-supported kernel containing the applicable stable fix.
Prioritize embedded and appliance fleets that use UBI or UBIFS flash storage.
Check downstream Linux vendor guidance for corrected package versions.
Plan controlled testing because kernel updates may affect device stability and recovery.
Validation and detection
Inventory devices using UBI or UBIFS and record their exact kernel builds.
Compare package provenance or source ancestry with the listed stable fix commits.
Review monitoring for UBIFS background threads consuming sustained CPU after flash errors.
Confirm the deployed vendor kernel includes both early-return and locking corrections.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2023-53481 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
9Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.