CVE-2023-53778

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/qaic: Clean up integer overflow checking in map_user_pages()<br /> <br /> The encode_dma() function has some validation on in_trans-&gt;size but it<br /> would be more clear to move those checks to find_and_map_user_pages().<br /> <br /> The encode_dma() had two checks:<br /> <br /> if (in_trans-&gt;addr + in_trans-&gt;size addr || !in_trans-&gt;size)<br /> return -EINVAL;<br /> <br /> The in_trans-&gt;addr variable is the starting address. The in_trans-&gt;size<br /> variable is the total size of the transfer. The transfer can occur in<br /> parts and the resources-&gt;xferred_dma_size tracks how many bytes we have<br /> already transferred.<br /> <br /> This patch introduces a new variable "remaining" which represents the<br /> amount we want to transfer (in_trans-&gt;size) minus the amount we have<br /> already transferred (resources-&gt;xferred_dma_size).<br /> <br /> I have modified the check for if in_trans-&gt;size is zero to instead check<br /> if in_trans-&gt;size is less than resources-&gt;xferred_dma_size. If we have<br /> already transferred more bytes than in_trans-&gt;size then there are negative<br /> bytes remaining which doesn&amp;#39;t make sense. If there are zero bytes<br /> remaining to be copied, just return success.<br /> <br /> The check in encode_dma() checked that "addr + size" could not overflow<br /> and barring a driver bug that should work, but it&amp;#39;s easier to check if<br /> we do this in parts. First check that "in_trans-&gt;addr +<br /> resources-&gt;xferred_dma_size" is safe. Then check that "xfer_start_addr +<br /> remaining" is safe.<br /> <br /> My final concern was that we are dealing with u64 values but on 32bit<br /> systems the kmalloc() function will truncate the sizes to 32 bits. So<br /> I calculated "total = in_trans-&gt;size + offset_in_page(xfer_start_addr);"<br /> and returned -EINVAL if it were &gt;= SIZE_MAX. This will not affect 64bit<br /> systems.