[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YaZqt7bwSJtS2SaT@e110455-lin.cambridge.arm.com>
Date: Tue, 30 Nov 2021 18:17:27 +0000
From: Liviu Dudau <liviu.dudau@....com>
To: Zhou Qingyang <zhou1615@....edu>
Cc: kjlu@....edu, "James (Qian) Wang" <james.qian.wang@....com>,
Mihail Atanassov <mihail.atanassov@....com>,
Brian Starkey <brian.starkey@....com>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/komeda: Fix an undefined behavior bug in
komeda_plane_add()
Hi Zhou,
On Tue, Nov 30, 2021 at 10:23:01PM +0800, Zhou Qingyang wrote:
> In komeda_plane_add(), komeda_get_layer_fourcc_list() is assigned to
> formats and used in drm_universal_plane_init().
> drm_universal_plane_init() passes formats to
> __drm_universal_plane_init(). __drm_universal_plane_init() further
> passes formats to memcpy() as src parameter, which could lead to an
> undefined behavior bug on failure of komeda_get_layer_fourcc_list().
>
> Fix this bug by adding a check of formats.
>
> This bug was found by a static analyzer. The analysis employs
> differential checking to identify inconsistent security operations
> (e.g., checks or kfrees) between two code paths and confirms that the
> inconsistent operations are not recovered in the current function or
> the callers, so they constitute bugs.
>
> Note that, as a bug found by static analysis, it can be a false
> positive or hard to trigger. Multiple researchers have cross-reviewed
> the bug.
If multiple researchers have cross-reviewed the bug how many have reviewed the fix?
I'm asking because there is a problem with the fix ....
>
> Builds with CONFIG_DRM_KOMEDA=m show no new warnings,
> and our static analyzer no longer warns about this code.
>
> Fixes: 61f1c4a8ab75 ("drm/komeda: Attach komeda_dev to DRM-KMS")
> Signed-off-by: Zhou Qingyang <zhou1615@....edu>
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> index d63d83800a8a..dd3f17e970dd 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> @@ -265,6 +265,10 @@ static int komeda_plane_add(struct komeda_kms_dev *kms,
>
> formats = komeda_get_layer_fourcc_list(&mdev->fmt_tbl,
> layer->layer_type, &n_formats);
> + if (!formats) {
> + err = -ENOMEM;
> + goto cleanup;
If you go to cleanup here it is too early, as the plane variable has not been
initialised by the drm_universal_plane_init(), so komeda_plane_destroy() will crash.
The correct fix here is to free the kplane allocation and then return -ENOMEM.
> + }
>
> err = drm_universal_plane_init(&kms->base, plane,
> get_possible_crtcs(kms, c->pipeline),
> --
> 2.25.1
>
Best regards,
Liviu
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
Powered by blists - more mailing lists