[{"id":3685479,"web_url":"http://patchwork.ozlabs.org/comment/3685479/","msgid":"<20260504024421.D5256C2BCB4@smtp.kernel.org>","list_archive_url":null,"date":"2026-05-04T02:44:21","subject":"Re: [PATCH v2] PCI/proc: check user access return values in\n proc_bus_pci_{read,write}()","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] Integer truncation in proc_bus_pci_write allows negative offsets to bypass bounds checks, leading to out-of-bounds PCI accesses and soft lockups.\n- [Medium] Error handling discards partial transfers, violating POSIX semantics and risking unintended side effects on retry.\n--\n\ncommit e7bdf9d788abd98223b783ee67cefeac2bfdde52\nAuthor: Deepanshu Kartikey \n\nPCI/proc: check user access return values in proc_bus_pci_{read,write}()\n\nThis commit replaces __get_user() and __put_user() with get_user() and\nput_user() to check for user access faults during PCI config space reads\nand writes. It removes the upfront access_ok() check and adds an error\npath to release the runtime PM reference and return -EFAULT on failure.\n\n> diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c\n> index ce36e35681e8..8e624d829840 100644\n> --- a/drivers/pci/proc.c\n> +++ b/drivers/pci/proc.c\n> @@ -53,15 +53,13 @@ static ssize_t proc_bus_pci_read(struct file *file, char __user *buf,\n> \t\tnbytes = size - pos;\n> \tcnt = nbytes;\n> \n> -\tif (!access_ok(buf, cnt))\n> -\t\treturn -EINVAL;\n> -\n> \tpci_config_pm_runtime_get(dev);\n> \n> \tif ((pos & 1) && cnt) {\n> \t\tunsigned char val;\n> \t\tpci_user_read_config_byte(dev, pos, &val);\n> -\t\t__put_user(val, buf);\n> +\t\tif (put_user(val, buf))\n> +\t\t\tgoto err;\n> \t\tbuf++;\n> \t\tpos++;\n> \t\tcnt--;\n> @@ -70,7 +68,8 @@ static ssize_t proc_bus_pci_read(struct file *file, char __user *buf,\n> \tif ((pos & 3) && cnt > 2) {\n> \t\tunsigned short val;\n> \t\tpci_user_read_config_word(dev, pos, &val);\n> -\t\t__put_user(cpu_to_le16(val), (__le16 __user *) buf);\n> +\t\tif (put_user(cpu_to_le16(val), (__le16 __user *) buf))\n> +\t\t\tgoto err;\n\nIf a fault happens during this put_user() call, some bytes may have already\nbeen successfully transferred by the previous call. Unconditionally jumping\nto the err label and returning -EFAULT discards this partial progress and\nfails to update *ppos.\n\nSince configuration registers can be stateful, such as Write-1-to-Clear\nbits, could userspace retrying the entire operation cause unintended side\neffects?\n\nIf data has been successfully processed prior to a fault, should the function\nupdate the file offset and return the number of bytes transferred instead?\n\n[ ... ]\n> @@ -106,6 +108,10 @@ static ssize_t proc_bus_pci_read(struct file *file, char __user *buf,\n> \n> \t*ppos = pos;\n> \treturn nbytes;\n> +\n> +err:\n> +\tpci_config_pm_runtime_put(dev);\n> +\treturn -EFAULT;\n> }\n> \n> static ssize_t proc_bus_pci_write(struct file *file, const char __user *buf,\n\nThis issue isn't introduced by the patch, but does this function truncate\n*ppos? Looking at the full function:\n\nstatic ssize_t proc_bus_pci_write(struct file *file, const char __user *buf,\n\t\t\t\t size_t nbytes, loff_t *ppos)\n{\n\t...\n\tint pos = *ppos;\n\t...\n\nIf a large positive offset is passed, such as 2294967296, the assignment to\nthe 32-bit int pos would truncate it to a negative value.\n\nThis bypasses the if (pos >= size) check. When checking pos + nbytes > size,\npos is promoted to a 64-bit size_t and sign-extends to a huge value, making\nthe condition true. nbytes is then calculated as size - pos, resulting in a\nmassive positive integer for cnt.\n\n[ ... ]\n> @@ -154,7 +159,8 @@ static ssize_t proc_bus_pci_write(struct file *file, const char __user *buf,\n> \n> \twhile (cnt >= 4) {\n> \t\t__le32 val;\n> -\t\t__get_user(val, (__le32 __user *) buf);\n> +\t\tif (get_user(val, (__le32 __user *) buf))\n> +\t\t\tgoto err;\n> \t\tpci_user_write_config_dword(dev, pos, le32_to_cpu(val));\n> \t\tbuf += 4;\n> \t\tpos += 4;\n> \t\tcnt -= 4;\n\nThe while (cnt >= 4) loop would then execute hundreds of millions of times,\npassing a negative offset to the configuration accessor functions.\n\nSince proc_bus_pci_write() lacks a cond_resched() call in this loop, could\nthis trigger a soft lockup?","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=fuOKvoeE;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-53652-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=\"fuOKvoeE\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::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 4g85Zd6XSLz1yJV\n\tfor ; Mon, 04 May 2026 12:44:25 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 1C41D30087B1\n\tfor ; Mon, 4 May 2026 02:44:23 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 88A111E1A3D;\n\tMon, 4 May 2026 02:44:22 +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 659E61A6813\n\tfor ; Mon, 4 May 2026 02:44:22 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id D5256C2BCB4;\n\tMon, 4 May 2026 02:44:21 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777862662; cv=none;\n b=WGvbjwr5j/4IP9U2lUBiNyCFD/sP6xm6QAAPI3uNwgOJnX3tH8cU7Vu02y6wa7Z4bMzGzeJunprft3E3a1nEdkoLT3UuhqmaKpbphAKT2t7pykWHnLq7YLWnS1uoL7/LVMTrpVwtZlA5YXO6tUaoFcYCB896nDJcM4GfWDEEgb4=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777862662; c=relaxed/simple;\n\tbh=sB68pW06hUAe/bMcHU1XLpdRkQsqCGW3tOUdo6fTh0Q=;\n\th=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date:\n\t Message-Id;\n b=O+V7EJznfNlyYVUFrCewRSCzAYkW8F1/hi+foQBKiDYoMQcE9pfNtcPdodDoBtbEt/rFxXrMm/CxpWgC+hglVCX7OQ+NNxSzIbKendVM86oa5CSt8PhloJAY9GL1ONL8NKRaTwy0JW5fAMC4X67yFs4dGuZVL+0raPeKTyIF9fc=","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=fuOKvoeE; 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=1777862662;\n\tbh=sB68pW06hUAe/bMcHU1XLpdRkQsqCGW3tOUdo6fTh0Q=;\n\th=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From;\n\tb=fuOKvoeEKOUinN/mEMUztVD6LC9FuP8w9IL6yf9yKnt3V0I6AkptMtnetxx/e8pR1\n\t Z04SAf2EcUBOdr3Q1S6cABID2i6zdK/F9/NEywIkJu4PYR2MkA47vRIQjIx0xVLWBY\n\t k9PK1TyGrnShtW5M29rFw6LYAjxH+C5omIAB5yj9TyGkr9UXvW7yQb4oABgANcgFUq\n\t qL+0tWMcD/ffaJsBxcO/NhNk7skLs3qHU41+d9Lgzm/ZCvV+TP7xjKMOjoiaG9iUxe\n\t 4ZUwk9Lqo2KiulxY5XL/NXFvcbatXB7Xlc2xDA2Gj66h+FwLxaR8ZNm62Kpox8Szoq\n\t rsbUB3D1zpIjA==","From":"sashiko-bot@kernel.org","Subject":"Re: [PATCH v2] PCI/proc: check user access return values in\n proc_bus_pci_{read,write}()","Reply-To":"sashiko@lists.linux.dev","To":"\"Deepanshu Kartikey\" ","Cc":"linux-pci@vger.kernel.org","In-Reply-To":"<20260504022231.15501-1-kartikey406@gmail.com>","References":"<20260504022231.15501-1-kartikey406@gmail.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","Date":"Mon, 04 May 2026 02:44:21 +0000","Message-Id":"<20260504024421.D5256C2BCB4@smtp.kernel.org>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":""}}]