CVE-2023-53778

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

accel/qaic: Clean up integer overflow checking in map_user_pages()

The encode_dma() function has some validation on in_trans->size but it

would be more clear to move those checks to find_and_map_user_pages().

The encode_dma() had two checks:

if (in_trans->addr + in_trans->size < in_trans->addr || !in_trans->size)

return -EINVAL;

The in_trans->addr variable is the starting address. The in_trans->size

variable is the total size of the transfer. The transfer can occur in

parts and the resources->xferred_dma_size tracks how many bytes we have

already transferred.

This patch introduces a new variable "remaining" which represents the

amount we want to transfer (in_trans->size) minus the amount we have

already transferred (resources->xferred_dma_size).

I have modified the check for if in_trans->size is zero to instead check

if in_trans->size is less than resources->xferred_dma_size. If we have

already transferred more bytes than in_trans->size then there are negative

bytes remaining which doesn't make sense. If there are zero bytes

remaining to be copied, just return success.

The check in encode_dma() checked that "addr + size" could not overflow

and barring a driver bug that should work, but it's easier to check if

we do this in parts. First check that "in_trans->addr +

resources->xferred_dma_size" is safe. Then check that "xfer_start_addr +

remaining" is safe.

My final concern was that we are dealing with u64 values but on 32bit

systems the kmalloc() function will truncate the sizes to 32 bits. So

I calculated "total = in_trans->size + offset_in_page(xfer_start_addr);"

and returned -EINVAL if it were >= SIZE_MAX. This will not affect 64bit

systems.