linux-kernel - Re: [PATCH 08/29] drm/atomic: Only call atomic_destroy

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: <20250915-dangerous-industrious-gecko-b25b7b@penduick>
Date: Mon, 15 Sep 2025 13:35:45 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>, Andrzej Hajda <andrzej.hajda@...el.com>, 
	Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>, Jonas Karlman <jonas@...boo.se>, 
	Jernej Skrabec <jernej.skrabec@...il.com>, Jyri Sarha <jyri.sarha@....fi>, 
	Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, Devarsh Thakkar <devarsht@...com>, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 08/29] drm/atomic: Only call atomic_destroy_state on a
 !NULL pointer

On Tue, Sep 02, 2025 at 10:52:47PM +0200, Laurent Pinchart wrote:
> On Tue, Sep 02, 2025 at 10:32:36AM +0200, Maxime Ripard wrote:
> > The drm_atomic_state structure is freed through the
> > drm_atomic_state_put() function, that eventually calls
> > drm_atomic_state_default_clear() by default when there's no active
> > users of that state.
> > 
> > It then iterates over all entities with a state, and will call the
> 
> Did you mean s/with a state/within the state/ ?

I'm not sure how to phrase it, but I meant "entities" that have a
matching state structure. Encoders for example don't.

> I'd also replace "entity" with "object" as mentioned in the review of a
> previous patch.

And bridges aren't objects :/

> > atomic_destroy_state callback on the state pointer. The state pointer is
> > mostly used these days to point to which of the old or new state needs
> > to be freed, depending on whether the state was committed or not.
> > 
> > So it all makes sense.
> > 
> > However, with the hardware state readout support approaching, we might
> > have a state, with multiple entities in it, but no state to free because
> > we want them to persist. In such a case, state is going to be NULL, and
> > thus we'll end up with NULL pointer dereference.
> 
> I'm not sure to follow you here. Are we talking with objects whose old
> and new states will both need to be preserved ? Or objects that have no
> old state ?

It's more of the latter, but not really. Objects, at this point of the
series, will always have an old state.

However, due to how the initial state is being built with hardware
readout, we would move the old state of an entity/object/whatever to
$object->state, and clear it from drm_atomic_state so it's not freed.

so drm_atomic_state ends up with a whole bunch of objects that don't
have an old state anymore, and drm_atomic_state_default_clear() chokes
on that.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)