CVE-2021-47638: ubifs: rename_whiteout: Fix double free for whiteout_ui->data
In the Linux kernel, the following vulnerability has been resolved:
ubifs: rename_whiteout: Fix double free for whiteout_ui->data
'whiteout_ui->data' will be freed twice if space budget fail for
rename whiteout operation as following process:
rename_whiteout
dev = kmalloc
whiteout_ui->data = dev
kfree(whiteout_ui->data) // Free first time
iput(whiteout)
ubifs_free_inode
kfree(ui->data) // Double free!
KASAN reports:
==================================================================
BUG: KASAN: double-free or invalid-free in ubifs_free_inode+0x4f/0x70
Call Trace:
kfree+0x117/0x490
ubifs_free_inode+0x4f/0x70 [ubifs]
i_callback+0x30/0x60
rcu_do_batch+0x366/0xac0
__do_softirq+0x133/0x57f
Allocated by task 1506:
kmem_cache_alloc_trace+0x3c2/0x7a0
do_rename+0x9b7/0x1150 [ubifs]
ubifs_rename+0x106/0x1f0 [ubifs]
do_syscall_64+0x35/0x80
Freed by task 1506:
kfree+0x117/0x490
do_rename.cold+0x53/0x8a [ubifs]
ubifs_rename+0x106/0x1f0 [ubifs]
do_syscall_64+0x35/0x80
The buggy address belongs to the object at ffff88810238bed8 which
belongs to the cache kmalloc-8 of size 8
==================================================================
Let ubifs_free_inode() free 'whiteout_ui->data'. BTW, delete unused
assignment 'whiteout_ui->data_len = 0', process 'ubifs_evict_inode()
-> ubifs_jnl_delete_inode() -> ubifs_jnl_write_inode()' doesn't need it
(because 'inc_nlink(whiteout)' won't be excuted by 'goto out_release',
and the nlink of whiteout inode is 0).
Security readout for executives and security teams
Plain-English summary
This Linux kernel flaw can crash affected systems when a UBIFS rename whiteout operation hits a space-budget failure path. The issue is a double free, meaning kernel memory is released twice. The CVSS impact is availability only, but a crash on affected systems can still disrupt operations.
Executive priority
Treat as a moderate operational reliability risk. Prioritize patching where affected Linux systems use UBIFS in production, embedded, or appliance-like roles. Lower urgency is reasonable for systems without UBIFS exposure or where vendor kernels already include the stable fix.
Technical view
CVE-2021-47638 is a CWE-415 double free in UBIFS rename_whiteout handling. whiteout_ui->data could be freed on the error path, then freed again during inode cleanup through ubifs_free_inode(). KASAN showed the double free in ubifs_free_inode(). The fix leaves that cleanup to ubifs_free_inode().
Likely exposure
Relevant exposure is Linux systems running affected kernel builds with UBIFS in use. The source lists local attack vector and low privileges required. Systems not using UBIFS or already carrying the referenced stable fixes are less likely to be exposed.
Exploitation context
The CVE is not listed as CISA KEV in the provided bundle, and no cited source claims active exploitation. Exploitation requires local access with privileges sufficient to trigger the vulnerable filesystem behavior. The documented security impact is high availability impact, not confidentiality or integrity loss.
Researcher notes
Evidence supports a local availability-impact double free in UBIFS error handling. The source bundle provides kernel stable references and KASAN trace details, but does not provide exploit proof, active exploitation, or product-specific distribution advisories. Validate exposure by filesystem use and backport status.
Mitigation direction
Apply vendor kernel updates that include the referenced UBIFS stable fixes.
Confirm distribution kernels have backported the relevant fix, not just a higher version string.
Prioritize systems that mount or depend on UBIFS for operational workloads.
If no update is available, follow vendor guidance for temporary risk reduction.
Limit local access on affected UBIFS systems until remediation is complete.
Validation and detection
Inventory Linux kernel versions and vendor patch levels across affected assets.
Identify systems where UBIFS is mounted, loaded, or required by the platform.
Map installed kernels against the CVE record and referenced stable commits.
Review crash, KASAN, or kernel logs for UBIFS double-free indicators.
Confirm remediation through vendor advisory status or fixed kernel package metadata.
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.
cwe · low confidence lookup
CWE-415: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
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.
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.