CVE-2023-53271 in Linux
Summary
by MITRE • 09/16/2025
In the Linux kernel, the following vulnerability has been resolved:
ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume()
There is a memory leaks problem reported by kmemleak:
unreferenced object 0xffff888102007a00 (size 128): comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s) hex dump (first 32 bytes): ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace: [<ffffffff8176cecd>] __kmalloc+0x4d/0x150
[<ffffffffa02a9a36>] ubi_eba_create_table+0x76/0x170 [ubi]
[<ffffffffa029764e>] ubi_resize_volume+0x1be/0xbc0 [ubi]
[<ffffffffa02a3321>] ubi_cdev_ioctl+0x701/0x1850 [ubi]
[<ffffffff81975d2d>] __x64_sys_ioctl+0x11d/0x170
[<ffffffff83c142a5>] do_syscall_64+0x35/0x80
[<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
This is due to a mismatch between create and destroy interfaces, and in detail that "new_eba_tbl" created by ubi_eba_create_table() but destroyed by kfree(), while will causing "new_eba_tbl->entries" not freed.
Fix it by replacing kfree(new_eba_tbl) with ubi_eba_destroy_table(new_eba_tbl)
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 01/11/2026
The vulnerability CVE-2023-53271 represents a memory leak issue within the Linux Unified Block Interface (UBI) subsystem that affects the ubi_resize_volume() function. This memory leak occurs when the kernel's memory management system detects an unreferenced object that remains allocated in memory even after it should have been freed. The issue manifests through kmemleak analysis which identifies a 128-byte memory block at address 0xffff888102007a00 that has been allocated but never properly deallocated. The object was created by the ubi_eba_create_table() function and is associated with a process named "ubirsvol" with process identifier 32090, indicating this is likely a UBI volume resize operation that triggered the memory management error.
The root cause of this vulnerability stems from an interface mismatch in the memory management pattern used within the UBI subsystem. Specifically, the code creates a new EBA (Erasure Block Allocator) table using ubi_eba_create_table() but subsequently attempts to free it using the generic kfree() function instead of the proper cleanup function ubi_eba_destroy_table(). This discrepancy creates a memory leak because kfree() only frees the memory allocated for the table structure itself but does not properly clean up the internal entries array that was allocated during table creation. The backtrace clearly shows the call path leading to the issue through ubi_resize_volume(), which is invoked via ioctl system calls, demonstrating how this vulnerability can be triggered through normal UBI volume management operations.
This memory leak vulnerability has significant operational implications for systems running Linux kernels with UBI support, particularly those utilizing flash storage devices such as NAND flash memory. The persistent memory leak can lead to gradual memory exhaustion over time, especially in systems that frequently perform volume resize operations or have high UBI activity. The leaked memory blocks accumulate and can eventually impact system performance, potentially causing memory pressure that affects other kernel subsystems or even system stability. According to CWE classification, this represents a CWE-401: Improper Release of Memory Before Removing Last Reference, which is a well-known category of memory management flaws that can lead to resource exhaustion attacks. The vulnerability also aligns with ATT&CK technique T1070.004: File and Directory Permissions Modification, as improper memory management can be exploited to maintain persistence or cause denial of service conditions.
The fix for CVE-2023-53271 is straightforward but critical for maintaining proper memory management within the UBI subsystem. The solution involves replacing the incorrect kfree() call with the appropriate ubi_eba_destroy_table() function call that properly handles the cleanup of both the table structure and its internal entries array. This change ensures that all allocated memory within the EBA table is properly freed according to the design patterns established for the UBI subsystem. The fix demonstrates the importance of maintaining consistent memory management interfaces within kernel subsystems and highlights the necessity of proper resource cleanup when working with complex data structures that contain nested allocations. System administrators should apply this patch immediately to all systems running affected Linux kernels to prevent potential memory exhaustion issues and maintain system stability, particularly in embedded systems or devices that rely heavily on UBI for flash storage management operations.