[{"id":3687359,"web_url":"http://patchwork.ozlabs.org/comment/3687359/","msgid":"<20260506202223.0D971C2BCB0@smtp.kernel.org>","list_archive_url":null,"date":"2026-05-06T20:22:22","subject":"Re: [PATCH v6 6/6] vfio/pci: Add PCIe TPH SET_ST interface","submitter":{"id":93311,"url":"http://patchwork.ozlabs.org/api/people/93311/","name":null,"email":"sashiko-bot@kernel.org"},"content":"Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:\n- [High] Incorrect `argsz` size validation unconditionally rejects valid ioctl requests.\n- [Medium] The unused `st` field in `struct vfio_pci_tph_entry` is not validated for being zero during SET_ST, breaking forward ABI compatibility.\n--\n\ncommit cad3760ab856857766102c878427138245e1feb6\nAuthor: Chengwen Feng \n\nvfio/pci: Add PCIe TPH SET_ST interface\n\nThis commit adds the VFIO_PCI_TPH_SET_ST operation to support batch\nprogramming of steering tag entries. It also implements a rollback\nmechanism to clear successfully programmed entries if any entry fails\nto prevent inconsistent device state.\n\n> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c\n> index 45e641ab2a887..867d8694b56bd 100644\n> --- a/drivers/vfio/pci/vfio_pci_core.c\n> +++ b/drivers/vfio/pci/vfio_pci_core.c\n[ ... ]\n> @@ -1600,6 +1600,90 @@ static int vfio_pci_tph_get_st(struct vfio_pci_core_device *vdev,\n> \treturn err;\n> }\n> \n> +static int vfio_pci_tph_set_st(struct vfio_pci_core_device *vdev,\n> +\t\t\t struct vfio_device_pci_tph_op *op,\n> +\t\t\t void __user *uarg)\n> +{\n> +\tstruct pci_dev *pdev = vdev->pdev;\n> +\tstruct vfio_pci_tph_entry *ents;\n> +\tstruct vfio_pci_tph_st st;\n[ ... ]\n> +\tsize = st.count * sizeof(*ents);\n> +\tif (op->argsz < offsetofend(struct vfio_device_pci_tph_op, st) +\n> +\t\t\tsizeof(struct vfio_pci_tph_st) + size)\n> +\t\treturn -EINVAL;\n\nDoes adding sizeof(struct vfio_pci_tph_st) artificially inflate the required\nbuffer size?\n\nThe offsetofend() macro already includes the size of the st member. If a\nproperly written userspace application computes its argsz exactly as\nsizeof(struct vfio_device_pci_tph_op) + size, this check would fail and\nreject the request with -EINVAL.\n\n> +\n> +\tents = kvmalloc(size, GFP_KERNEL);\n> +\tif (!ents)\n> +\t\treturn -ENOMEM;\n> +\n> +\tents_off = offsetof(struct vfio_pci_tph_st, ents);\n> +\tif (copy_from_user(ents, uarg + ents_off, size)) {\n> +\t\terr = -EFAULT;\n> +\t\tgoto out;\n> +\t}\n> +\n> +\tfor (; i < st.count; i++) {\n> +\t\t/* Check reserved fields are zero */\n> +\t\tif (memchr_inv(&ents[i].reserved0, 0, sizeof(ents[i].reserved0)) ||\n> +\t\t memchr_inv(&ents[i].reserved1, 0, sizeof(ents[i].reserved1))) {\n> +\t\t\terr = -EINVAL;\n> +\t\t\tgoto out;\n> +\t\t}\n\nDuring the SET_ST operation, the st field in struct vfio_pci_tph_entry\nappears to be unused, as the steering tag is instead dynamically fetched\nvia pcie_tph_get_cpu_st() later in the loop.\n\nShould the st field also be validated to be zero?\n\nIf userspace leaves this unused field uninitialized and passes garbage data,\nit might break forward ABI compatibility. A future kernel update that attempts\nto read explicit steering tags directly from this field wouldn't be able to\ndistinguish between old programs sending uninitialized garbage and new\nprograms sending valid data.\n\n[ ... ]","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=M8bqd4AB;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-53946-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"M8bqd4AB\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g9myW5cD8z1yJq\n\tfor ; Thu, 07 May 2026 06:22:27 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id B0BCC30166DE\n\tfor ; Wed, 6 May 2026 20:22:24 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id D528B3128CA;\n\tWed, 6 May 2026 20:22:23 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id B1822131E49\n\tfor ; Wed, 6 May 2026 20:22:23 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 0D971C2BCB0;\n\tWed, 6 May 2026 20:22:23 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778098943; cv=none;\n b=RvWFl4NDvwVxsfSDcxCc6cFio5hg6XOyG2ysZWqvSnGOKNRYquIoRSVF1WEIVmllQPuDHJRZpLtQKwia+ymQ/l7Dwyj3Q+jUe7QNXWUfpGrehdX7tnIvy254oMb5xBfae0YbUV5BCJRxi+WCCpo6I5o/kIbxB9Pl8JHjSri1SZM=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778098943; c=relaxed/simple;\n\tbh=Q4cOMIhkG1dO1XEn9ipd2Cy3hjV6SkdwDM3MYMNlx2A=;\n\th=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date:\n\t Message-Id;\n b=VkklV+3HFjaLxNmkJRPC/R7J9RnUNTiKAELNDO4EoAC7dEy3+TPwUI2mNHA06aG6u7bYuQNWC/2AAcLHfYlm/0+y4gmDiseBmeiyJnp0NtdbbtOl+LXRCtDX71PvyMOI9E07Pt8bzNytI85KC5ajJGTM24JegYL3ixVp3Op4DMI=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=M8bqd4AB; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1778098943;\n\tbh=Q4cOMIhkG1dO1XEn9ipd2Cy3hjV6SkdwDM3MYMNlx2A=;\n\th=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From;\n\tb=M8bqd4ABTf+Nnb6l4XbQY8HhQ/iMfkMBubJGMOfEviB1m30gCo4ufVwABOzexi9kR\n\t iRsTzG9wjAQdRrt+Zz0/YqoV237y7XEs9po7+ZBA0jpDgm9ZLdNUZduf+AjPghWBJ+\n\t 3o+pnLf9G5LHZrgHoSGivNKUat2OgFn5JKnhA5gavtqsMfI5P/Tk3xc/hPAwWOeNXR\n\t +tkLBsdNvI1L0MXGcMDLiaS9Nn17Ilan2l0HBXVQih93W25nlP7o9fEN2K1ItrC2GF\n\t gl9bZgeZu7L32d5N10bo8seiS/xlTNsARBBJDd8gi9XM6nSf0URALGWq+K7FkVAe9k\n\t KsCf+byb1Qsaw==","From":"sashiko-bot@kernel.org","Subject":"Re: [PATCH v6 6/6] vfio/pci: Add PCIe TPH SET_ST interface","Reply-To":"sashiko@lists.linux.dev","To":"\"Chengwen Feng\" ","Cc":"linux-pci@vger.kernel.org","In-Reply-To":"<20260506094623.29327-7-fengchengwen@huawei.com>","References":"<20260506094623.29327-7-fengchengwen@huawei.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","Date":"Wed, 06 May 2026 20:22:22 +0000","Message-Id":"<20260506202223.0D971C2BCB0@smtp.kernel.org>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":""}}]