From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1268615A86D for ; Sat, 18 Jul 2026 23:54:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784418882; cv=none; b=Vuw+pGOXBjWs2lz3xLJcYzb5TL9qSKZWvVvRksY3Hf0SLyFMZUokswnvb0lLsd9lnraBMpMnRjn4D+EyQjQddVa2zZvf0YebIeAWvYmGJ626kYD0ABRBJ3CYdq+T3LIcvs3w8ByJMmXhsnL15AXZWr5sIrcTO5jPiV/J5wBVpWA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784418882; c=relaxed/simple; bh=ENJ1kFA9pkGWYtOg011EJSPSvZLjdaLOlQ359cKe5Qo=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=HVSaFUS/Dzy0I62ZQ89oUmj8euRM96M5IpIQkiUS3pkewo+Ro6ZMvLiHIHT84uI3fLUqWN1UkPle1EeCYlDKcHAdWY2DUDDPv2xWFXN1X2SwjD9zdETsKiL8yxSlbieL5rAjlBxGtyyDg0R6dxHf1hu1DVlLVnLIn3PYqPGr6TA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TU2/0IaU; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TU2/0IaU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5664F1F000E9; Sat, 18 Jul 2026 23:54:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784418880; bh=nHUy++hDRX3zDmfeKYf9s2cnoNqoIu2sJqwOijvW2f4=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=TU2/0IaU8zD0v85PljVEtfywQY4KiZ1DQDKVaQBmTPPKH7JnlKNg9dVti5XcizzRE ATUVK4n59C1hrUqp7okt0VDtvKMAIxfjprkkdrp0CjYJqA/waON5y8zpWlu3b4sASf tsa96v1wORx8aVOv8UM242iQ5juDZ87YdoCCeZWpWkLT+0dZJh3B/bGUNWgljlKFNB 2ExPbKn8ezpakLXBZp1ZiujKKrPNHm/KOrapof4Iy7Rjbw4tkHh20R/gPWsgDX4zeA iPKMkyMSR0VS6md2HjRGFIYqqZrmuvJblDjvmJgubxRhiY8ePcujv9QTBN11kySZfK QB7Hl+ebbJqfQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH 07/15] drm/tidss: remove dependency on DRM simple helpers Reply-To: sashiko-reviews@lists.linux.dev To: "Diogo Silva" Cc: linux-amlogic@lists.infradead.org, dri-devel@lists.freedesktop.org, wsa+renesas@sang-engineering.com, imx@lists.linux.dev, Frank.Li@kernel.org, neil.armstrong@linaro.org In-Reply-To: <20260719-drm_simple_encoder_init-v1-7-a78c509e3062@gmail.com> References: <20260719-drm_simple_encoder_init-v1-0-a78c509e3062@gmail.com> <20260719-drm_simple_encoder_init-v1-7-a78c509e3062@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 18 Jul 2026 23:54:39 +0000 Message-Id: <20260718235440.5664F1F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: imx@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: Pre-existing issues: - [High] Use-After-Free during teardown due to object lifetime mismatch bet= ween `drm_bridge` and `drm_encoder`. -- --- Patch [7]: [PATCH 07/15] drm/tidss: remove dependency on DRM simple hel= pers --- commit e6abfa8d59d485697fcfe2a3a199e7f378a7e23a Author: Diogo Silva drm/tidss: remove dependency on DRM simple helpers The patch removes the deprecated simple KMS helpers from the tidss driver. It replaces drm_simple_encoder_init() with a direct call to drm_encoder_init(), providing driver-local drm_encoder_funcs to handle cleanup. > diff --git a/drivers/gpu/drm/tidss/tidss_encoder.c b/drivers/gpu/drm/tids= s/tidss_encoder.c > index 698f8d964ca00..10dbcc6cdf6a8 100644 > --- a/drivers/gpu/drm/tidss/tidss_encoder.c > +++ b/drivers/gpu/drm/tidss/tidss_encoder.c [ ... ] > @@ -81,6 +81,10 @@ static const struct drm_bridge_funcs tidss_bridge_func= s =3D { > .atomic_destroy_state =3D drm_atomic_helper_bridge_destroy_state, > }; > =20 > +static const struct drm_encoder_funcs tidss_encoder_funcs =3D { > + .destroy =3D drm_encoder_cleanup, > +}; > + > int tidss_encoder_create(struct tidss_device *tidss, > struct drm_bridge *next_bridge, > u32 encoder_type, u32 possible_crtcs) > @@ -95,8 +99,8 @@ int tidss_encoder_create(struct tidss_device *tidss, > if (IS_ERR(t_enc)) > return PTR_ERR(t_enc); > =20 > - ret =3D drm_simple_encoder_init(&tidss->ddev, &t_enc->encoder, > - encoder_type); > + ret =3D drm_encoder_init(&tidss->ddev, &t_enc->encoder, > + &tidss_encoder_funcs, encoder_type, NULL); [Severity: High] This is a pre-existing issue, but can this lead to a use-after-free during teardown due to mismatched object lifetimes? In tidss_encoder_create(), the t_enc structure is allocated via devm_drm_bridge_alloc(), which ties the memory's lifetime to the bridge's kref. Then the embedded encoder is initialized here and its destroy callback is s= et to drm_encoder_cleanup() in tidss_encoder_funcs. If the driver unbinds while a userspace application holds a DRM file descriptor, devm drops the initial bridge references. Later, when the final DRM reference is dropped, drm_mode_config_cleanup() calls the encoder's destroy callback. Inside drm_encoder_cleanup(), it detaches the bridge. This drops the final kref and frees the t_enc container. However, drm_encoder_cleanup() then continues to access the freed encoder memory, causing a use-after-free. Does this sequence cause memory corruption during teardown? > if (ret) > return ret; > --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260719-drm_simple= _encoder_init-v1-0-a78c509e3062@gmail.com?part=3D7