linux-kernel - Re: [PATCH] drm/tinydrm: mipi-dbi: Fix unbalanced DMA access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 3 Aug 2017 17:41:02 -0500
From:   David Lechner <david@...hnology.com>
To:     dri-devel@...ts.freedesktop.org
Cc:     Noralf Trønnes <noralf@...nnes.org>,
        David Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/tinydrm: mipi-dbi: Fix unbalanced DMA access

On 08/01/2017 03:14 PM, David Lechner wrote:
> If we return here and import_attach is true, then dma_buf_end_cpu_access()
> will not be called balance dma_buf_begin_cpu_access().
> 
> Fix by setting ret instead of returning.
> 
> Signed-off-by: David Lechner <david@...hnology.com>
> ---
>   drivers/gpu/drm/tinydrm/mipi-dbi.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c b/drivers/gpu/drm/tinydrm/mipi-dbi.c
> index c83eeb7..e10fa4b 100644
> --- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
> +++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
> @@ -183,7 +183,8 @@ static int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
>   		dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
>   			     drm_get_format_name(fb->format->format,
>   						 &format_name));
> -		return -EINVAL;
> +		ret = -EINVAL;
> +		break;
>   	}
>   
>   	if (import_attach)
> 


I just realized that the next line here can mask ret.


	if (import_attach)
		ret = dma_buf_end_cpu_access(import_attach->dmabuf,
					     DMA_FROM_DEVICE);

So, we should either ignore the return value from 
dma_buf_end_cpu_access() always or add some logic to ignore it if ret is 
already an error.

In some of the other patches I have been sending, we have the same 
situation. I those, I have opted to just ignore the return value from 
dma_buf_end_cpu_access(). e.g...


	if (import_attach)
		dma_buf_end_cpu_access(import_attach->dmabuf, DMA_FROM_DEVICE);

Is this a reasonable thing to do?