No CVE-2022-39842 aka int/size_t confusion in pxa3xx_gcu_write()

[Alexey Dobriyan <adobriyan@gmail.com>]

> From a09d2d00af53b43c6f11e6ab3cb58443c2cac8a7 Mon Sep 17 00:00:00 2001
> From: Hyunwoo Kim <imv4bel@gmail.com>
> Date: Mon, 20 Jun 2022 07:17:46 -0700
> Subject: [PATCH 1/1] video: fbdev: pxa3xx-gcu: Fix integer overflow in pxa3xx_gcu_write
> 
> In pxa3xx_gcu_write, a count parameter of type size_t is passed to words of
> type int.  Then, copy_from_user() may cause a heap overflow because it is used
> as the third argument of copy_from_user().
> 
> --- a/drivers/video/fbdev/pxa3xx-gcu.c
> +++ b/drivers/video/fbdev/pxa3xx-gcu.c
> @@ -381,7 +381,7 @@ pxa3xx_gcu_write(struct file *file, const char *buff,
>  	struct pxa3xx_gcu_batch	*buffer;
>  	struct pxa3xx_gcu_priv *priv = to_pxa3xx_gcu_priv(file);
>  
> -	int words = count / 4;
> +	size_t words = count / 4;
>  
>  	/* Does not need to be atomic. There's a lock in user space,
>  	 * but anyhow, this is just for statistics. */

This patch is predicated on the fact that struct file_operations::write
may accept arbitrary "size_t count" values" which is not true:

	ssize_t vfs_write(struct file *file, const char __user *buf, size_t count, loff_t *pos)
	{
		...
		if (count > MAX_RW_COUNT)
	                count =  MAX_RW_COUNT;

This check clamps everything at "INT_MAX & ~PAGE_MASK" which is within int
value range so it can be divided and multiplied back just fine.

Another thing, on x86_64 copy_from_user/copy_to_user() _real_ signature is

	unsigned long copy_user_generic(void *, const void *, unsigned !!!)

Note how "unsigned long len" becomes just "unsigned int len" right when you
are tired to follow the callchain. Assembly does "movl %edx, %ecx" and other
32-bit things.

So... No CVE?