CVE-2022-49771

In the Linux kernel, the following vulnerability has been resolved:

dm ioctl: fix misbehavior if list_versions races with module loading

_listversions will first estimate the required space using the "dmtargetiterate(listversiongetneeded, &needed)" call and then will fill the space using the "dmtargetiterate(listversiongetinfo, &iterinfo)" call. Each of these calls locks the targets using the "downread(&lock)" and "upread(&lock)" calls, however between the first and second "dmtargetiterate" there is no lock held and the target modules can be loaded at this point, so the second "dmtargetiterate" call may need more space than what was the first "dmtarget_iterate" returned.

The code tries to handle this overflow (see the beginning of listversionget_info), however this handling is incorrect.

The code sets "param->datasize = param->datastart + needed" and "iterinfo.end = (char *)vers+len" - "needed" is the size returned by the first dmtarget_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->datasize is set to "needed", so it may write data past the param->datasize 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 "iterinfo.end = (char *)vers + needed;" - this guarantees that the second "dmtargetiterate" call will write only up to the "needed" buffer and it will exit with "DMBUFFERFULLFLAG" 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 listversionget_needed - we need to add "strlen(tt->name) + 1" to the needed size, not "strlen(tt->name)".