linux-kernel - Re: [PATCH v3 4/8] drm/msm/dpu: use drmm_writeback_connector

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]

Message-ID: <78c764b8-44cf-4db5-88e7-807a85954518@wanadoo.fr>
Date: Mon, 8 Sep 2025 23:09:07 +0200
From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
To: "dmitry.baryshkov@....qualcomm.com >> Dmitry Baryshkov"
 <dmitry.baryshkov@....qualcomm.com>
Cc: abhinav.kumar@...ux.dev, airlied@...il.com, alexander.deucher@....com,
 amd-gfx@...ts.freedesktop.org, christian.koenig@....com,
 dave.stevenson@...pberrypi.com, dri-devel@...ts.freedesktop.org,
 freedreno@...ts.freedesktop.org, geert+renesas@...der.be,
 harry.wentland@....com, jani.nikula@...ux.intel.com,
 jessica.zhang@....qualcomm.com, kernel-list@...pberrypi.com,
 kieran.bingham+renesas@...asonboard.com,
 laurent.pinchart+renesas@...asonboard.com, linux-arm-msm@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
 liviu.dudau@....com, louis.chauvet@...tlin.com, lumag@...nel.org,
 maarten.lankhorst@...ux.intel.com, magnus.damm@...il.com,
 marijn.suijten@...ainline.org, mcanal@...lia.com, mripard@...nel.org,
 robin.clark@....qualcomm.com, sean@...rly.run, simona@...ll.ch,
 siqueira@...lia.com, sunpeng.li@....com, suraj.kandpal@...el.com,
 tomi.valkeinen+renesas@...asonboard.com, tzimmermann@...e.de
Subject: Re: [PATCH v3 4/8] drm/msm/dpu: use drmm_writeback_connector_init()

Le 19/08/2025 à 22:32, Dmitry Baryshkov a écrit :
> Use drmm_plain_encoder_alloc() to allocate simple encoder and
> drmm_writeback_connector_init() in order to initialize writeback
> connector instance.
> 
> Reviewed-by: Louis Chauvet <louis.chauvet-LDxbnhwyfcJBDgjK7y7TUQ@...lic.gmane.org>
> Reviewed-by: Suraj Kandpal <suraj.kandpal-ral2JQCrhuEAvxtiuMwx3w@...lic.gmane.org>
> Reviewed-by: Jessica Zhang <jessica.zhang-5oFBVzJwu8Ry9aJCnZT0Uw@...lic.gmane.org>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov-5oFBVzJwu8Ry9aJCnZT0Uw@...lic.gmane.org>
> ---
>   drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 10 +++-------
>   1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c
> index 8ff496082902b1ee713e806140f39b4730ed256a..cd73468e369a93c50303db2a7d4499bcb17be5d1 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c
> @@ -80,7 +80,6 @@ static int dpu_wb_conn_atomic_check(struct drm_connector *connector,
>   static const struct drm_connector_funcs dpu_wb_conn_funcs = {
>   	.reset = drm_atomic_helper_connector_reset,
>   	.fill_modes = drm_helper_probe_single_connector_modes,
> -	.destroy = drm_connector_cleanup,
>   	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>   	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>   };
> @@ -131,12 +130,9 @@ int dpu_writeback_init(struct drm_device *dev, struct drm_encoder *enc,
>   
>   	drm_connector_helper_add(&dpu_wb_conn->base.base, &dpu_wb_conn_helper_funcs);
>   
> -	/* DPU initializes the encoder and sets it up completely for writeback
> -	 * cases and hence should use the new API drm_writeback_connector_init_with_encoder
> -	 * to initialize the writeback connector
> -	 */
> -	rc = drm_writeback_connector_init_with_encoder(dev, &dpu_wb_conn->base, enc,
> -			&dpu_wb_conn_funcs, format_list, num_formats);
> +	rc = drmm_writeback_connector_init(dev, &dpu_wb_conn->base,
> +					   &dpu_wb_conn_funcs, enc,
> +					   format_list, num_formats);
>   
>   	if (!rc)
>   		dpu_wb_conn->wb_enc = enc;
> 

dpu_wb_conn is allocated a few lines above using devm_kzalloc().

Based on [1], mixing devm_ and drmm_ is not safe and can lead to a uaf.

Is it correct here?
If the explanation at [1] is correct, then &dpu_wb_conn->base would 
point to some released memory, IIUC.


just my 2c.

CJ

[1]: 
https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/xe/xe_hwmon.c?id=3a13c2de442d6bfaef9c102cd1092e6cae22b753