Received-SPF: pass (google.com: domain of linux-kernel+bounces-109809-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: mathieu.poirier@linaro.org
Cc: andersson@kernel.org,
	matthias.bgg@gmail.com,
	angelogioacchino.delregno@collabora.com,
	tzungbi@kernel.org,
	tinghan.shen@mediatek.com,
	linux-remoteproc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org,
	wenst@chromium.org,
	kernel@collabora.com
Subject: [PATCH 0/2] MediaTek SCP: Urgent fixes for all MTK SoCs
Date: Thu, 21 Mar 2024 09:46:12 +0100
Message-ID: <20240321084614.45253-1-angelogioacchino.delregno@collabora.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This series brings some missing validation for the IPI buffer size
that is read from the firmware retrieved from userspace: if the FW
declares IPI buffer offset starting at an out of range address, the
driver doesn't do any validation and naively goes on with IO R/W
operation.

That poses various risks which I believe I really don't need to
describe, leaving it to the reader's imagination :-)

Please note that the first fix is URGENT.

P.S.: Of course, this was tested OK on multiple MTK platforms.

AngeloGioacchino Del Regno (2):
  remoteproc: mediatek: Make sure IPI buffer fits in L2TCM
  remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

 drivers/remoteproc/mtk_scp.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

-- 
2.44.0