CVE-2022-49771 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
dm ioctl: fix misbehavior if list_versions races with module loading
__list_versions will first estimate the required space using the "dm_target_iterate(list_version_get_needed, &needed)" call and then will fill the space using the "dm_target_iterate(list_version_get_info, &iter_info)" call. Each of these calls locks the targets using the "down_read(&_lock)" and "up_read(&_lock)" calls, however between the first and second "dm_target_iterate" there is no lock held and the target modules can be loaded at this point, so the second "dm_target_iterate" call may need more space than what was the first "dm_target_iterate" returned.
The code tries to handle this overflow (see the beginning of list_version_get_info), however this handling is incorrect.
The code sets "param->data_size = param->data_start + needed" and "iter_info.end = (char *)vers+len" - "needed" is the size returned by the first dm_target_iterate call; "len" is the size of the buffer allocated by userspace.
"len" may be greater than "needed"; in this case, the code will write up to "len" bytes into the buffer, however param->data_size is set to "needed", so it may write data past the param->data_size value. The ioctl interface copies only up to param->data_size into userspace, thus part of the result will be truncated.
Fix this bug by setting "iter_info.end = (char *)vers + needed;" - this guarantees that the second "dm_target_iterate" call will write only up to the "needed" buffer and it will exit with "DM_BUFFER_FULL_FLAG" if it overflows the "needed" space - in this case, userspace will allocate a larger buffer and retry.
Note that there is also a bug in list_version_get_needed - we need to add "strlen(tt->name) + 1" to the needed size, not "strlen(tt->name)".
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 01/16/2026
The vulnerability described in CVE-2022-49771 resides within the Linux kernel's device mapper subsystem, specifically in the dm ioctl interface handling of version listing operations. This flaw manifests as a race condition that can lead to buffer overflows and data truncation during the enumeration of device mapper targets. The issue occurs when the kernel attempts to list version information for loaded device mapper targets through a two-phase process that involves estimating required buffer space and then populating that space with actual target information. The vulnerability is particularly concerning as it affects the core device mapper functionality that underpins various storage management operations including logical volume management and disk encryption.
The technical implementation of this vulnerability stems from a fundamental flaw in the locking mechanism and buffer management during the version listing process. The kernel's __list_versions function employs a two-step approach where it first estimates the required space using dm_target_iterate with list_version_get_needed callback, and then fills the buffer using dm_target_iterate with list_version_get_info callback. While each iteration properly acquires and releases the target lock using down_read and up_read operations, there exists a critical gap between these two operations where no lock is held. This race condition allows target modules to be loaded or unloaded during the interim period, causing the second dm_target_iterate call to require more space than initially estimated. The vulnerability is categorized under CWE-362 as a race condition and aligns with ATT&CK technique T1059.003 for execution through kernel modules.
The operational impact of this vulnerability extends beyond simple buffer overflow conditions to potentially compromise system stability and security. When the race condition occurs, the kernel's buffer management logic incorrectly calculates the final buffer boundaries, leading to situations where data is written beyond the intended buffer limits. The specific bug in the parameter calculation sets param->data_size to param->data_start + needed instead of properly accounting for the actual buffer size, causing data to be written past the intended boundary. This results in partial data truncation where only portions of the version information are correctly returned to userspace, potentially leading to incomplete or corrupted device mapper target information. The vulnerability can be exploited by malicious actors to disrupt storage operations or potentially gain unauthorized access to system resources through manipulation of device mapper targets.
The fix implemented for CVE-2022-49771 addresses the core issue by modifying how the buffer end pointer is calculated during the second dm_target_iterate call. The solution changes the assignment from iter_info.end = (char )vers + len - needed to iter_info.end = (char )vers + needed, ensuring that the second iteration will respect the originally calculated buffer size. This modification guarantees that when the second iteration exceeds the allocated space, it will properly exit with DM_BUFFER_FULL_FLAG, allowing userspace to detect the overflow and allocate a larger buffer for retry. Additionally, the fix corrects a secondary bug in list_version_get_needed where it was not properly accounting for the null terminator in target name string lengths. The mitigation strategy requires updating to kernel versions that include this patch, and system administrators should prioritize applying these updates to prevent potential exploitation of this race condition. The vulnerability demonstrates the importance of proper locking mechanisms and buffer boundary calculations in kernel space operations, particularly when dealing with dynamic module loading scenarios.