All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Maxime Ripard" <mripard@kernel.org>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v6 06/28] drm/atomic_sro: Create drm_atomic_sro_state container
Date: Thu, 15 Oct 2026 15:41:21 +0000	[thread overview]
Message-ID: <sashiko-outbox-173085@kernel.org> (raw)
In-Reply-To: <20261015-drm-state-readout-v6-6-6cc02cd10998@kernel.org>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] drm/atomic_sro: heap out-of-bounds array access due to sparse connector IDA
- [Medium] drm: connector reference leak in drm_atomic_sro_state_free() when conn_state is NULL
- [Low] drm: incorrect error code -EINVAL on OOM in drm_atomic_sro_state_alloc()
--

commit 7fa33b0c7c68e508f3bb44a6225923e6e800d132
Author: Maxime Ripard <mripard@kernel.org>

drm/atomic_sro: Create drm_atomic_sro_state container

The SRO infrastructure needs a state container to collect the readout states
for all KMS objects. Unlike drm_atomic_commit which tracks old and new states
for atomic commits, this container only holds a single state per object. This
commit creates struct drm_atomic_sro_state with arrays for planes, CRTCs,
connectors, and private objects.

> diff --git a/drivers/gpu/drm/drm_atomic_sro.c b/drivers/gpu/drm/drm_atomic_sro.c
> new file mode 100644
> index 0000000000000..096fdb7088190
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_atomic_sro.c
[ ... ]
> +static int drm_atomic_sro_state_init(struct drm_device *dev,
> +				     struct drm_atomic_sro_state *state)
> +{
> +	int err;
> +
> +	state->planes =
> +		kzalloc_objs(*state->planes, dev->mode_config.num_total_plane);
> +	if (!state->planes)
> +		return -ENOMEM;
> +
> +	state->crtcs = kzalloc_objs(*state->crtcs, dev->mode_config.num_crtc);
> +	if (!state->crtcs) {
> +		err = -ENOMEM;
> +		goto err_free_planes;
> +	}
> +
> +	state->connectors = kzalloc_objs(*state->connectors,
> +					 dev->mode_config.num_connector);

[Severity: High]
Does allocating the array using num_connector account for sparse IDA indices?
Connector indices are allocated dynamically and can exceed the active
connector count if connectors are hotplugged or removed. Using num_connector
as the size limits the array, which may cause out-of-bounds access when
indexed directly.

> +	if (!state->connectors) {
> +		err = -ENOMEM;
> +		goto err_free_crtcs;
> +	}
> +
> +	state->private_objs =
> +		kzalloc_objs(*state->private_objs, count_private_obj(dev));
> +	if (!state->private_objs)  {
> +		err = -ENOMEM;
> +		goto err_free_connectors;
> +	}
> +
> +	state->num_private_objs = 0;
> +
> +	drm_dev_get(dev);
> +	state->dev = dev;
> +
> +	return 0;
> +
> +err_free_connectors:
> +	kfree(state->connectors);
> +err_free_crtcs:
> +	kfree(state->crtcs);
> +err_free_planes:
> +	kfree(state->planes);
> +	return err;
> +}
> +
> +/**
> + * drm_atomic_sro_state_alloc - allocate an SRO state container
> + * @dev: DRM device to allocate the state for
> + *
> + * Allocates and initializes a &struct drm_atomic_sro_state that can hold
> + * readout states for all KMS objects on @dev.
> + *
> + * The returned state must be freed with drm_atomic_sro_state_free().
> + *
> + * RETURNS:
> + *
> + * A new &struct drm_atomic_sro_state on success, an error pointer on
> + * failure.
> + */
> +struct drm_atomic_sro_state *drm_atomic_sro_state_alloc(struct drm_device *dev)
> +{
> +	struct drm_atomic_sro_state *state;
> +	int ret;
> +
> +	state = kzalloc_obj(*state);
> +	if (!state)
> +		return ERR_PTR(-EINVAL);

[Severity: Low]
Should this return -ENOMEM instead of -EINVAL when memory allocation fails?

> +
> +	ret = drm_atomic_sro_state_init(dev, state);
> +	if (ret) {
> +		kfree(state);
> +		return ERR_PTR(ret);
> +	}
> +
> +	return state;
> +}
> +EXPORT_SYMBOL(drm_atomic_sro_state_alloc);
> +
> +/**
> + * drm_atomic_sro_state_free - free an SRO state container
> + * @state: SRO state to free
> + *
> + * Frees a &struct drm_atomic_sro_state previously allocated with
> + * drm_atomic_sro_state_alloc().
> + */
> +void drm_atomic_sro_state_free(struct drm_atomic_sro_state *state)
> +{
> +	struct drm_device *dev = state->dev;
> +	unsigned int i;
> +
> +	for (i = 0; i < state->num_private_objs; i++) {
> +		struct drm_private_obj *obj = state->private_objs[i].ptr;
> +		struct drm_private_state *obj_state = state->private_objs[i].state;
> +
> +		if (!obj || !obj_state)
> +			continue;
> +
> +		obj->funcs->atomic_destroy_state(obj, obj_state);
> +		state->private_objs[i].state = NULL;
> +		state->private_objs[i].ptr = NULL;
> +	}
> +
> +	kfree(state->private_objs);
> +
> +	for (i = 0; i < state->dev->mode_config.num_connector; i++) {

[Severity: High]
Does iterating up to the live num_connector cause out-of-bounds reads?
Since num_connector can increase after the SRO state was allocated if
connectors are added, this loop might read past the end of the originally
allocated state->connectors array.

> +		struct drm_connector *conn = state->connectors[i].ptr;
> +		struct drm_connector_state *conn_state =
> +			state->connectors[i].state;
> +
> +		if (!conn || !conn_state)
> +			continue;

[Severity: Medium]
Does this skip drm_connector_put() and leak the reference if conn is valid but
conn_state is NULL? 
In drm_atomic_sro_set_connector_state(), drm_connector_get() unconditionally
takes a reference on conn and stores it. If conn_state is NULL during cleanup,
the early continue bypasses drm_connector_put() completely.

> +
> +		conn->funcs->atomic_destroy_state(conn, conn_state);
> +		state->connectors[i].state = NULL;
> +		state->connectors[i].ptr = NULL;
> +		drm_connector_put(conn);
> +	}
> +
[ ... ]
> +/**
> + * drm_atomic_sro_set_connector_state - store a connector state into an SRO state
> + * @state: SRO state container
> + * @conn: connector the state belongs to
> + * @conn_state: connector state to store
> + *
> + * Takes a reference on @conn which is released when the state is
> + * installed or freed.
> + */
> +void drm_atomic_sro_set_connector_state(struct drm_atomic_sro_state *state,
> +					struct drm_connector *conn,
> +					struct drm_connector_state *conn_state)
> +{
> +	unsigned int index = drm_connector_index(conn);
> +
> +	drm_connector_get(conn);
> +	state->connectors[index].ptr = conn;

[Severity: High]
Can this write out of bounds?
Since the connectors array was allocated using num_connector rather than
accommodating sparse indices, a connector with an index greater than or equal
to num_connector will cause this write to overwrite heap memory.

> +	state->connectors[index].state = conn_state;
> +
> +	drm_dbg_atomic(conn->dev,
> +		       "Added [CONNECTOR:%d:%s] %p state to readout state %p\n",
> +		       conn->base.id, conn->name, conn_state, state);
> +}
> +EXPORT_SYMBOL(drm_atomic_sro_set_connector_state);
> +
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015-drm-state-readout-v6-0-6cc02cd10998@kernel.org?part=6

  reply	other threads:[~2026-10-15 15:41 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 15:08 [PATCH v6 00/28] drm: Implement state readout support Maxime Ripard
2026-10-15 15:08 ` [PATCH v6 01/28] drm/atomic: Fix private obj error handling Maxime Ripard
2026-10-15 15:23   ` sashiko-bot
2026-10-15 15:08 ` [PATCH v6 02/28] drm/atomic: Add drm_private_obj name Maxime Ripard
2026-10-15 15:23   ` sashiko-bot
2026-10-15 15:08 ` [PATCH v6 03/28] drm/bridge: Switch print_state to use bridge name Maxime Ripard
2026-10-15 15:34   ` sashiko-bot
2026-10-15 15:08 ` [PATCH v6 04/28] drm/bridge: Add drm_private_obj_is_bridge() Maxime Ripard
2026-10-15 15:28   ` sashiko-bot
2026-10-15 15:08 ` [PATCH v6 05/28] drm/atomic: Export drm_atomic_*_print_state Maxime Ripard
2026-10-15 15:33   ` sashiko-bot
2026-10-15 15:08 ` [PATCH v6 06/28] drm/atomic_sro: Create drm_atomic_sro_state container Maxime Ripard
2026-10-15 15:41   ` sashiko-bot [this message]
2026-10-15 15:08 ` [PATCH v6 07/28] drm/atomic_sro: Create kernel parameter to force or disable readout Maxime Ripard
2026-10-15 15:46   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 08/28] drm/atomic_sro: Add atomic state readout infrastructure Maxime Ripard
2026-10-15 15:52   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 09/28] drm/atomic_sro: Add function to install state into drm objects Maxime Ripard
2026-10-15 15:56   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 10/28] drm/atomic_sro: Create documentation Maxime Ripard
2026-10-15 15:59   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 11/28] drm/bridge: Handle bridges with hardware state readout Maxime Ripard
2026-10-15 16:05   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 12/28] drm/mode-config: Read out hardware state in drm_mode_config_create_state Maxime Ripard
2026-10-15 16:14   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 13/28] drm/atomic_sro: Provide helpers to implement hardware state readout Maxime Ripard
2026-10-15 16:21   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 14/28] drm/mode-config: Introduce hw_reset hook Maxime Ripard
2026-10-15 15:09 ` [PATCH v6 15/28] drm/modeset-helper: Add drm_mode_config_helper_hw_reset() Maxime Ripard
2026-10-15 15:09 ` [PATCH v6 16/28] drm/atomic_helper: Compare actual and readout states once the commit is done Maxime Ripard
2026-10-15 16:31   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 17/28] drm/atomic-state-helper: Provide comparison macros Maxime Ripard
2026-10-15 16:39   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 18/28] drm/atomic-state-helper: Provide atomic_compare_state helpers Maxime Ripard
2026-10-15 16:50   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 19/28] drm/atomic-helper: Document State Read-Out as a state initialization approach Maxime Ripard
2026-10-15 16:53   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 20/28] drm/encoder: Create atomic_sro_get_current_crtc hook Maxime Ripard
2026-10-15 15:09 ` [PATCH v6 21/28] drm/bridge: display-connector: Implement readout support Maxime Ripard
2026-10-15 16:59   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 22/28] drm/bridge_connector: Implement hw readout for connector Maxime Ripard
2026-10-15 16:59   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 23/28] drm/tidss: crtc: Add atomic_print_state implementation Maxime Ripard
2026-10-15 15:09 ` [PATCH v6 24/28] drm/tidss: dispc: Improve mode checking logs Maxime Ripard
2026-10-15 17:02   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 25/28] drm/tidss: Implement hw_reset Maxime Ripard
2026-10-15 17:09   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 26/28] drm/tidss: Implement readout support Maxime Ripard
2026-10-15 17:13   ` sashiko-bot
2026-10-15 15:09 ` [PATCH v6 27/28] drm/tidss: encoder: Implement atomic_sro_get_current_crtc Maxime Ripard
2026-10-15 15:09 ` [PATCH v6 28/28] drm/bridge: sii902x: Implement hw state readout Maxime Ripard
2026-10-15 17:20   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-173085@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=mripard@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.