CVE-2022-50743 in Linux
Summary
by MITRE • 12/24/2025
In the Linux kernel, the following vulnerability has been resolved:
erofs: Fix pcluster memleak when its block address is zero
syzkaller reported a memleak: https://syzkaller.appspot.com/bug?id=62f37ff612f0021641eda5b17f056f1668aa9aed
unreferenced object 0xffff88811009c7f8 (size 136): ... backtrace: [<ffffffff821db19b>] z_erofs_do_read_page+0x99b/0x1740
[<ffffffff821dee9e>] z_erofs_readahead+0x24e/0x580
[<ffffffff814bc0d6>] read_pages+0x86/0x3d0
...
syzkaller constructed a case: in z_erofs_register_pcluster(), ztailpacking = false and map->m_pa = zero. This makes pcl->obj.index be zero although pcl is not a inline pcluster.
Then following path adds refcount for grp, but the refcount won't be put because pcl is inline.
z_erofs_readahead() z_erofs_do_read_page() # for another page z_erofs_collector_begin() erofs_find_workgroup() erofs_workgroup_get()
Since it's illegal for the block address of a non-inlined pcluster to be zero, add check here to avoid registering the pcluster which would be leaked.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 04/21/2026
The vulnerability CVE-2022-50743 represents a memory leak in the Linux kernel's erofs (Erofs Compressed File System) implementation that occurs when processing pcluster structures with zero block addresses. This issue was identified through systematic fuzzing by the syzkaller framework, which revealed a specific scenario where memory allocated for pcluster objects becomes unreferenced and cannot be properly freed. The memory leak manifests when the z_erofs_register_pcluster() function processes a pcluster with ztailpacking set to false and map->m_pa equal to zero, creating a condition where the pcluster object's index is incorrectly set to zero despite the pcluster not being inlined.
The technical flaw stems from improper validation of block addresses within the erofs filesystem driver, specifically in the handling of pcluster structures that are not inlined. When a non-inlined pcluster has a zero block address, the system incorrectly registers this pcluster without proper validation, leading to a reference count increment for the associated workgroup. The reference counting mechanism fails to properly decrement the reference count because the system assumes the pcluster is inline, but the actual pcluster structure is not inlined. This creates a dangling reference where the memory allocated for the pcluster object remains unreferenced and cannot be freed by the kernel's memory management subsystem.
The operational impact of this vulnerability extends beyond simple memory consumption, as it represents a potential denial of service vector that could lead to progressive memory exhaustion on systems running erofs filesystems. The vulnerability affects systems that utilize compressed filesystems, particularly those using the erofs implementation, and could be exploited through crafted filesystem images or specific access patterns that trigger the problematic code path. The memory leak occurs during read operations when the kernel attempts to process compressed pages, making it potentially exploitable through sustained read operations on affected filesystems. This type of memory management issue aligns with CWE-401: "Improper Release of Memory Before Removing Last Reference" and represents a classic case of resource leak in kernel space operations.
The mitigation strategy involves adding a validation check to prevent registration of pclusters with zero block addresses, which directly contradicts the filesystem's expected behavior that non-inlined pclusters must have valid block addresses. This fix ensures that invalid pcluster structures are rejected early in the processing pipeline, preventing the subsequent reference counting operations that lead to memory leaks. The solution follows established security practices for kernel vulnerability remediation by implementing early input validation and proper error handling. The fix addresses the root cause rather than symptoms, preventing the memory leak from occurring in the first place. This approach aligns with ATT&CK technique T1068: "Exploitation for Privilege Escalation" by ensuring proper memory management prevents potential exploitation through resource exhaustion attacks, and represents a fundamental improvement in kernel memory safety practices. The vulnerability demonstrates the importance of proper validation in kernel subsystems and highlights how seemingly minor implementation details can lead to significant security implications.