Re: [PATCH v6 14/16] power: sequencing: pcie-m2: Split Bluetooth unit based on interface

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Uninitialized `list_head` causes a NULL pointer dereference in `list_del` when cleaning up a power sequencer unit during a failed initialization.
--

--- Patch [14]: [PATCH v6 14/16] power: sequencing: pcie-m2: Split Bluetooth unit based on interface ---
commit f51366c358868b77076fdd6f12a8c7c1273f47d4
Author: Chen-Yu Tsai <wenst@chromium.org>

power: sequencing: pcie-m2: Split Bluetooth unit based on interface

Some UART / serdev based Bluetooth drivers need to be able to reset the
hardware during initialization or recovery. This is not possible with
the current power sequencing API if a unit is shared between USB and
UART interfaces.

> diff --git a/drivers/power/sequencing/pwrseq-pcie-m2.c b/drivers/power/sequencing/pwrseq-pcie-m2.c
> index 8ae55e87db74c..b713682a01ec4 100644
> --- a/drivers/power/sequencing/pwrseq-pcie-m2.c
> +++ b/drivers/power/sequencing/pwrseq-pcie-m2.c

[ ... ]

[Severity: High]
This is a pre-existing issue, but could this error path lead to a NULL pointer
dereference?

In drivers/power/sequencing/core.c:pwrseq_unit_setup():

	unit = pwrseq_unit_new(data);
	if (!unit)
		return ERR_PTR(-ENOMEM);

	if (data->deps) {
		ret = pwrseq_unit_setup_deps(data->deps, &unit->deps,
					     unit_list, processed_units);
		if (ret) {
			pwrseq_unit_put(unit);
			return ERR_PTR(ret);
		}
	}

If pwrseq_unit_setup_deps() fails, pwrseq_unit_put() is called, which
invokes pwrseq_unit_release():

static void pwrseq_unit_release(struct kref *ref)
{
	struct pwrseq_unit *unit = container_of(ref, struct pwrseq_unit, ref);

	pwrseq_unit_free_deps(&unit->deps);
	list_del(&unit->list);
	kfree_const(unit->name);
	kfree(unit);
}

Since unit was just allocated and unit->list has not been initialized with
INIT_LIST_HEAD() or added to any list yet (it is zero-initialized from
kzalloc), won't the unconditional call to list_del(&unit->list) dereference
the uninitialized prev/next pointers and cause a panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721065413.2306137-1-wenst@chromium.org?part=14